1 2 3 Previous Next 98 Replies Latest reply on Nov 11, 2015 11:24 PM by FotoHunter

    Полу-OFF про link aggregation на стеке...

    Umlyaut Expert

      Коллеги, добрый день!

       

      Вдогонку к недавней дискуссии о teaming физ.интерфейсов и пр. хочу поинтересоваться у тех, кто недавно имел дело со стеками свитчей, одним моментом, не освещённым в документации.

       

       

      Вот, к примеру, потенциальный кандидат - AT-8000GS/24. В спеках про LA на нём говорится, что LA-team (как и говорит стандарт) может иметь до 8 портов; самих LA-team может быть создано до 8 на устройство. Ещё спеки обещают (что, собственно, и привлекло внимание к данным комутаторам) "accross LA".

       

       

       

       

      А вот теперь возникает вопрос - на стеке из пары AT сколько можно будет создать LA-team - 8, 16, или... ???

       

       

       

       

      Как у кого на каких стеках с этим обстоят дела?

       

       

       

       

      ЗЫ: Я вчера даже создал тикет на саппорте Аллаеда - но его сразу

      закрыли без ответа (подозреваю, что их робот автоматом так отреагировал

      на отсутствие в поле формы создания тикета серийного номера их железяки - a где я его возьму, если железяка ещё не куплена?).

       

       

       

       

       

      ЗЗЫ: на случай недоумения публики - "а почему об этом нужно спрашивать именно тут?"...

       

       

      Дело в том, что я тут собрался с мыслями и вчерне расписал будущую (инфра)структуру своей Сферы. Обнаружилась интересная деталь - получается, что каждому из узлов (хостам ESX и нодам СХД) потребуется более одного LA-линка (по паре для каждой ноды СХД-кластера и по три каждому хосту ESX). Не, я понимаю, что можно некоторые LA-линки по 802.3ad с поддержкой стека свитчей заменить на FT-линки без таковой поддержки (например, на Service console хостов ESX), но при увеличении к-ва хостов/нод и этого может оказаться недостаточно.

        • 1. Re: Полу-OFF про link aggregation на стеке...
          Umlyaut Expert

          Ну вот и прояснилось... Специалисты Allied-Moscow ответили, что стек (сколько бы в нём ни было коммутаторов - 2-6) позволит создать те же 8 LA-групп "на всё про всё "... Впрямую не говорили, но намекнули, что это, якобы, тоже "стандарт" (если не де-юре на уровне отраслевых спецификаций, то де-факто принятый у вендоров). Жалко им, штоле?

           

           

           

          Прискорбно, однако - придётся однозначно SC хостов ESX вешать на FT-группу (с дефолтной балансировкой актив/пассив), чтобы не занимать зазря LA. И надо будет поиграть с бондингом интерфейсов на нодах СХД - возможно удастся получить нормальный траффик на alb/tlb без поддержки свитчем... Эх...

          • 2. Re: Полу-OFF про link aggregation на стеке...
            RumataRus Master

            Не расстраивайтесь, коллега! Зато Вы поделились ценной информацией с сообществом...

            • 3. Re: Полу-OFF про link aggregation на стеке...
              VTsukanov Virtuoso

              С некой долей неуверенности (очень давно было) на стеке Nortel-а ограничение было в 6 групп LACP.

              • 4. Re: Полу-OFF про link aggregation на стеке...
                Umlyaut Expert

                2 RumataRus:

                 

                VTsukanov wrote:

                С некой долей неуверенности (очень давно было) на стеке Nortel-а ограничение было в 6 групп LACP.

                 

                Видимо, каждый вендор дудит в свою дуду.

                Интересно, сколько там было "на девайс"? Если столько же, то, видимо, это какое-то общее место - когда объединяем свитчи в стек, то делаем это настолько seamless, что получившийся мегасвитч наследует буквально все логические сущности своих "долек".

                 

                И всё равно паршиво - на стек из, например, шести 24-ок (144 порта, на минуточку!) всего 8 LA-групп. А если делать на 48-ках, то эти 8 LA-групп приходятся уже на 288 портов. Ботва какая-то...

                • 5. Re: Полу-OFF про link aggregation на стеке...
                  VTsukanov Virtuoso

                  На девайс не помню ... про 6 то помню, потому что не хватало агрегированных портов для сторонних свичей.

                  Но честно сказать, у идеи из 144 портов в стеке есть и проблемные места - выход одной железки из строя приведет к краху всего

                  (а печальный опыт поиска битого кабелька, разборок с firmware стекируемых свичей имеется   )

                   

                  это, понятное дело, мое собственное мнение, никак не коррелирующее с мнением отделов маркетинга свичепроизводителей

                  • 6. Re: Полу-OFF про link aggregation на стеке...
                    MKorotko Expert

                    Но честно сказать, у идеи из 144 портов в стеке есть и проблемные места - выход одной железки из строя приведет к краху всего

                    (а печальный опыт поиска битого кабелька, разборок с firmware стекируемых свичей имеется )

                    </div>

                     

                    сам я с такими вещами не встречался, и не хотел встретиться, но вот слышал душераздирающую историю о подобном от одного знакомого сетевего инженера.

                     

                     

                    -


                    http://vm.pro-it.kz

                    • 7. Re: Полу-OFF про link aggregation на стеке...
                      Umlyaut Expert
                      VTsukanov wrote:VTsukanov wrote:

                      Но честно сказать, у идеи из 144 портов в стеке есть и проблемные места - выход одной железки из строя приведет к краху всего

                      </div>

                      С чего бы это???

                      Изначально (в т.ч. и в контексте данной дискуссии) предполагается, что стек будет использоваться нами (хорошо - мною ) как central point of connection для нашей виртуальной инфраструктуры (хосты ESX и ноды СХД).

                      Если мы делаем LA-группы таким образом, что порты, составляющие группу, более-менее равномерно "размазаны" по всем коммутаторам, составляющим  наш стек ("accross link aggregation") , то получается, что пока жив хоть один свитч из стека, то все LA-группы должны функционировать (пускай и с меньшей пропускной способностью относительно целого стека). Да и порты, предположительно не вошедшие в LA-группы (мало ли - ну не по 8 портов на группу потребовалось, а меньше), тоже могут быть spread по разным коммутаторам стека в рамках стратегий балансировки/фолт-толеранса, отличных от собственно LA/LACP.

                       

                       

                       

                       

                       

                       

                      (а печальный опыт поиска битого кабелька, разборок с firmware стекируемых свичей имеется  

                      </div>

                      Ну и что с того? "битый кабелёк" - он и в Африке "битый кабелёк": на этот случай и существует тестовый прогон оборудования (практика показывает, что если железка не крякает сразу, то потом, как правило, "живёт долго и счастливо").

                      На Ваш негативный опыт с "разборками с фирмварью" существует и контр-опыт благополучной работы оной. В этом плане стеки коммутаторов вряд ли можно считать (не)счастливым исключением в длинном ряду сложной IT-техники...

                      • 8. Re: Полу-OFF про link aggregation на стеке...
                        VTsukanov Virtuoso

                        С чего бы это???

                        Если у алиеда не так и то и слава богу ... но нортелах стек начинал себя вести мягко скажем неадекватно.

                        central point of connection для нашей виртуальной инфраструктуры (хосты ESX и ноды СХД).

                        144 физических порта для VI? Богато живете

                        тоже могут быть spread по разным коммутаторам стека в рамках стратегий балансировки/фолт-толеранса, отличных от собственно LA/LACP.

                        Не знаю оборудования - спорить не буду

                        если железка не крякает сразу, то потом, как правило, "живёт долго и счастливо").

                        Кабелек отработал года 3 до того как почить в бозе

                        На Ваш негативный опыт с "разборками с фирмварью" существует и контр-опыт благополучной работы оной.

                        Не вопрос, рад за вашу удачливость, я высказал сомнения в целесообразности, а не настаивал на своем личном мнении

                         

                         

                        По здравому размышлению вырисовалось объяснение ограничения количества LACP групп - с одной стороны - "20Gbps stacking bandwidth" этого как бы сказать для 8 групп IMHO даже маловато  - с другой стороны - коммутирующее быстродействие стека ничем не отличается от оного для одного свича, поэтому рестрикшены от свича плавно перетекли на стек.

                        • 9. Re: Полу-OFF про link aggregation на стеке...
                          RumataRus Master

                          Здравствуйте, коллега!

                          Только что вернулся от интеграторов.

                          У меня для нас с Вами "ошеломляющая" новость: мне мой интегратор говорит, что LA на стекированных коммутаторах AT-8000GS/24 не будет работать должным образом, поскольку AT-8000GS/24 не поддерживает Cisco Fast EtherChannel (FEC) и поэтому якобы полной отказоустойчивости не будет. Хотя я сам в Datasheet на AT-8000GS/24 читаю правильные с моей точки зрения фразы типа "Across stack link aggregation", "Link aggregation/trunking across stack", мне ему (интегратору) возразить нечего, но может быть Вы сможете?

                          • 10. Re: Полу-OFF про link aggregation на стеке...
                            Umlyaut Expert
                            VTsukanov wrote:

                            central point of connection для нашей виртуальной инфраструктуры (хосты ESX и ноды СХД).

                            144 физических порта для VI? Богато живете

                             

                            Ну, 144 порта - это был пример стека "на полную тягу" - из максимально разрешённых 6 юнитов. Себе я планирую стек из пары 24-к - согласитесь, 48 портов (из них, видимо, 8 сразу уйдёт на LA-группу в сторону "клиентского" 48-портового linkSYS`а) для VI - это не роскошь...

                             

                            VTsukanov wrote:

                            тоже могут быть spread по разным коммутаторам стека в рамках стратегий балансировки/фолт-толеранса, отличных от собственно LA/LACP.

                            Не знаю оборудования - спорить не буду

                             

                            А при чём тут оборудование? Балансировки, отличные от LA/LACP как раз в поддержке оборудования (т.е., свитча) не нуждаются - всё делается "на клиенте".

                             

                            VTsukanov wrote:

                            если железка не крякает сразу, то потом, как правило, "живёт долго и счастливо").

                            Кабелек отработал года 3 до того как почить в бозе

                             

                            Странно... Обычно, кабелям как раз по-барабану (если по ним не кататься чем-то твёрдо-острым)...

                             

                            VTsukanov wrote:

                             

                            По здравому размышлению вырисовалось объяснение ограничения количества LACP групп - с одной стороны - "20Gbps stacking bandwidth" этого как бы сказать для 8 групп IMHO даже маловато  - с другой стороны - коммутирующее быстродействие стека ничем не отличается от оного для одного свича, поэтому рестрикшены от свича плавно перетекли на стек.

                             

                            Не вяжется, Воля Ваша.

                            Посмотрим внимательнее - ""20Gbps stacking bandwidth" этого как бы сказать для 8 групп IMHO даже маловато" - а почему?

                             

                            На 24 порта имеем 24Gbit/s (закроем пока глаза на дуплекс и порождаемое им удвоение траффика - для удвоения будет та же картина) - это несколько больше производительности бэкбона в 20GBit/s, но не фатально -  можно считать, что мы в этом месте почти сбалансированы.

                            С чего бы это через 8 групп по 3 порта в каждой (равно как и через 4 группы по 6 портов или через 3 группы по 8 портов) вдруг "пролетел" бы трафф более 24GBit/s ???  Как логически не организовывай/объединяй порты - их общее кол-во (и проходящий по ним трафф) остаётся прежним.

                             

                            Да, в случае стека фиксированная производительность бэкбона будет разделена между бОльшим кол-вом портов на стеке. Ну и что?

                            Принцип-то тот же - как ни организовывай порты в группы, это не меняет суммарный траффик, проходящий через них.

                             

                            Лично меня гораздо больше устроила бы следующая возможность: максимальные кондиции девайса (неважно - сингл или стек) - 8 групп по 8 портов. НО! - если мне нужно, я могу уполовинить группу до 4-х портов ... и удвоить число групп (16 групп по 4 порта), оставаясь в рамках базовой кондиции. Либо 32 группы по 2 порта, либо 4 группы по 8 портов и 8 групп по 4 порта, не важно - думаю, суть Вы поняли.

                             

                            Вот где-то так...

                            • 11. Re: Полу-OFF про link aggregation на стеке...
                              Umlyaut Expert
                              RumataRus wrote:

                              Здравствуйте, коллега!

                              Только что вернулся от интеграторов.

                              У меня для нас с Вами "ошеломляющая" новость: мне мой интегратор говорит, что LA на стекированных коммутаторах AT-8000GS/24 не будет работать должным образом, поскольку AT-8000GS/24 не поддерживает Cisco Fast EtherChannel (FEC) и поэтому якобы полной отказоустойчивости не будет. Хотя я сам в Datasheet на AT-8000GS/24 читаю правильные с моей точки зрения фразы типа "Across stack link aggregation", "Link aggregation/trunking across stack", мне ему (интегратору) возразить нечего, но может быть Вы сможете?

                              </div>

                              Во-первых, какой-то у Вас интегратор несовременный - для гигабитной технологии у циско есть стандарт GEC (GigabitEtherChannel): да и говорим мы о семействе GS - при чём тут FEC???

                              .

                              А во-вторых, где дядька, а где бузина? Я понимаю, если режимы FEC/GEC выставлять на клиенте и требовать от Аллаедов работы в них - а тут-то с каких рыжиков влезли цисковские проприетарные протоколы (кстати, предшественники индустриального стандарта 802.3ad)???

                               

                              Нет, я могу понять, например, желание интегратора сделать сеть на Цисках - тогда можно превозносить фирменные цисковские фолт-толеранс-балансед-протоколы и поопускать индустриальные общие стандарты. Но вот так вот, как Вы описАли... гм-м-ммм...

                               

                              А потом, что значит полной отказоустойчивости не будет??? Это не разговор технарей, а ботва какая-то. У них есть реальные доказательства каких-то траблов с этим делом у Аллаеда (с описанием проблем), или на уровне "бла-бла-бла"???

                              • 12. Re: Полу-OFF про link aggregation на стеке...
                                RumataRus Master
                                Umlyaut wrote:

                                Во-первых, какой-то у Вас интегратор несовременный - для гигабитной технологии у циско есть стандарт GEC (GigabitEtherChannel): да и говорим мы о семействе GS - при чём тут FEC???

                                 

                                Ну в этом месте, положим я неточно выразился, интегратор говорил "FEC/GEC"

                                 

                                Нет, я могу понять, например, желание интегратора сделать сеть на Цисках

                                Ну я бы не сказал, что это желание очень острое, но действительно интегратор говорит, что на Cisco работать будет.

                                 

                                А потом, что значит "полной отказоустойчивости не будет"??? Это не разговор технарей, а ботва какая-то. У них есть реальные доказательства каких-то траблов с этим делом у Аллаеда (с описанием проблем), или на уровне "бла-бла-бла"???

                                 

                                На самом деле я интегратору выразил свое мнение на предмет того, что у меня есть прямо противоположная информация. В итогое ребята со своей стороны тоже пообещали к следующему понедельнику еще раз уточнить этот момент.

                                • 13. Re: Полу-OFF про link aggregation на стеке...
                                  Umlyaut Expert
                                  RumataRus wrote:

                                  >В итоге ребята со своей стороны тоже пообещали к следующему понедельнику еще раз уточнить этот момент.

                                   

                                  Я сейчас общался с дружественным интегратором (у нас с ними есть деловые отношения), так он обещал потрясти местный Аллаед на предмет дать мне пару 8000GS/24 погонять на стенде. Надеюсь, что вся процедура согласований будет завершена ещё в этом месяце и я смогу пощупать обсуждаемые девайсы в интересующем режиме лично (в т.ч., есс-но, и в в стеке в режиме LA)...

                                  • 14. Re: Полу-OFF про link aggregation на стеке...
                                    VTsukanov Virtuoso

                                    48 портов

                                    фух - стал понятен бюджет

                                    Вяжется .... не вяжется .... а почему?

                                    Спорить с вами, простите, не хочется, тем более спор получается с уклоном в арифметику - на свиче еще 4 сфп (не всегда пылится) и я исходил таки 144 портов.

                                    1 2 3 Previous Next