на сколько я помню он раз в какой-то интервайл замеряет нагрузку на линки и балансирует текущие и новые сессии по ним

не обязательно конечно

очень удобно, решает кучу проблем, но не обзяательно

но все остальное имеет очень мало смысла

естественно это работает при достаточно большом количестве достаточно равных flow

один флоу по двум линкам он не размазывает, чудес не бывает

при достаточно большом количестве достаточно равных потоков это не нужно абсолютно)

http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html

оно и так размажется хорошо

это надо как раз когда сессий мало и они разные

ну нет, не согласен

Based on what’s in that patent (after stripping away all the “we might also be patenting the spread of high-pressure water flows over coffee beans in espresso machine” stuff), it seems that Brocade’s hardware measures link delay and inter-link skew and combines that to schedule the frame transmission in a way that guarantees the frames will always be received in order by the remote switch. They don’t do receiver-side reordering (which is hard), but transmit-side delaying. Very clever solution deserving a huge WOOOOW.

ого

вот такого не ожидал

мне сложно себе представить как они заставили это работать

оно фактически размазывает по двум (или более) линкам не передачу фреймов, а молчание

но благодаря этому никакой application-based балансировки не нужно

но да, проприетарщина

да, решение классное, но в продакшене эти VCS Fabric ведут себя не очень, в первую очередь из-за того, что у брокадовского железа буферы мелкие, даже на mid-high level свичах и апгредить эту фабрику тяжело, хотя должен признать, она несколько гибче Nexus Fabric

а в каком смысле гибче?

"в продакшне ведут себя не очень, в первую очередь из-за того буферы мелкие" >такой-то пффф

мне они не понравились совсем

фабрика разваливается при малейшем пакетлоссе

ограничение на задержку между нодами жесткое

но про такие фичи я не знал

вот к примеру их vLAG, можно собрать LACP с двумя апстрим узлами VCS-фабрики, даже если эти два узла напрямую не соединены, тут фабри как полноценный единый виртуальный коммутатор, вот тут коротенько: http://www.brocade.com/content/html/en/deployment-guide/vcs-fabric-formation-multicast-dp/GUID-E8B7CB7D-D93B-4A2E-AB3F-A4324D3ED62D.html

вообще, у них идей много было хороших, но вот реализация страдала, а вместе с реализацией страдали и инженеры =)

ну может экстрим теперь с ними разберуться получше

я в упор не могу понять как они сделали такую балансировку

не с точки зрения идеи а с точки зрения имплементации

это ж с какой частотой надо поллить задержку

и как эту задержку мерять если с другой стороны не брокейд

ну нет, не согласен

аргументы..?

и как эту задержку мерять если с другой стороны не брокейд

задержка на физике предполагается одинаковой

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

задержка на физике предполагается одинаковой

это очень шаткое предположение

но скажем да

одинаковое, но какое?

а почему это важно?

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

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

да

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

но да, надо быть уверенными, что "там" не будет никаких сюрпризов

а если у меня один линк на оптике в метр длиной, а другой - километр?

это на задержку никак не влияет?

это хороший вопрос

вот как эту задержку померять

если с другой стороны брокейд то можно проприетарщину прикрутить

в обратном случае - не знаю

плюс задержка совсем не обязательно стабильная

аргументы..?

а почему оно вдруг хорошо размажется? как хеш посчитается, так и размажется, звёзды могут сойтись так, что 2/3 всего объёма лягут в единственный линк, всё зависит от достаточности энтропии для подсчета хеша, вот team как раз и позволит перебалансировать эти объемы для более-менее равно утилизации линков

если я её через дарк файбер какой-нить проложил

или, упаси боже, л2впн

а почему оно вдруг хорошо размажется? как хеш посчитается, так и размажется, звёзды могут сойтись так, что 2/3 всего объёма лягут в единственный линк, всё зависит от достаточности энтропии для подсчета хеша, вот team как раз и позволит перебалансировать эти объемы для более-менее равно утилизации линков

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

если мало и разные то тогда проблема

делать LAG где с одной стороны L2VPN а с другой стороны 5-метровый медный шнурок - хуёвая же архитектура, не? :)

делать LAG где с одной стороны L2VPN а с другой стороны 5-метровый медный шнурок - хуёвая же архитектура, не? :)

жутко

а хеш-алгоритм тут конечно не причем?

но если оба линка через л2впн то хрен знает как пойдут пакеты по каждому из них

а хеш-алгоритм тут конечно не причем?

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

мы ж не будем рассматривать случай хренового алгоритма

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

да это уже вопрос десятый

даже в банальном ЛАГе это хрен пойми как сделать

без МЛАГа

ну это к тому, что проприетарщину водрузить наверняка можно

ERROR: S client not available

ты тут стороны путаешь похоже

если это имплементировано только между двумя нодами одной фабрики - это совсем не так впечатляет

точнее впечатляет, но пользы от этого не много

ибо трафика там должно быть с гулькин нос

я не к тому, что трилл влияет на балансировку, ессно

просто доки раскуриваю

и из требований к этой адаптивной балансировке кажется, что да, это внутри фабрики

в банальном случае когда у меня с одной стороны один брокейд а с другой один не-брокейд

ну вот

а там только прямая оптика без всяких тебе впнов с очень маленькой задержкой

теперь логично)

именно

и бесполезно

но как proof-of-concept - прикольно

согласен

инженерам это ваять было наверно очень интересно

Agile ports allow the 4 interfaces to be merged on a hardware level. The main difference between this and a port-channel is that there is the traffic is not distributed across the bundle based on the flow hash, instead the hardware presents a single interface and applies bit striping across all lanes in parallel to get a true 40G pipe – there is no concept of flows or hashing, just bits in parallel.

ариста переплюнула

только если падает один линк - падают все

в сущности, программый qsfp

ну да

ещё более бесполезно

и здесь уже реально скорость света начинает проявлять себя

если в случае с брокадами плюс-минус бит тайм большую роль не сыграет, тот тут - еще как

если одна оптика будет на 2 метра длиннее другой - все, хана

тут жесткое ограничение на одинаковые сфп и одинаковую длину кабелей

с помощью нехитрых манипуляций из буханки хлеба...

есть набор целый.. злые рисунки, как так так называются)

http://weblinks.ru/blog/photo/1317.html

а есть что-то типа mactelnet только для ssh

http://lmgtfy.com/?q=mactelnet+for+ssh