Архитектура FCoE плат

Я достаточно долго очень скептически относился к шумихе вокруг новомодного ныне FCoE. Недостатков множество, большая их часть лежит на поверхности и не заметить их очень трудно. Это и расстояние, ограниченное всего 300 м., и отсутствие мультихоповости (с поддержкой FC портов пока нет ни у кого), принципиальная невозможность маршрутизации (layer 2, однако), затянувшийся процесс стандартизации протоколов, ну и конечно, кусачая цена.
Однако, активный пушинг этой технологии на рынок мега-корпорацией Cisco и догонялки других вендоров сделали свое дело. Насчет CEE и FCoE еще можно ворчать, но игнорировать их уже точно нельзя.

Честно признаюсь, ни одного случая использования FCoE в серьезном продуктиве я пока не знаю. Однако, во многих российских компаниях уже сейчас собирают стенды и начинают обкатывать такие решения. Для того, чтобы понимать чего сейчас можно и, что особенно важно, нельзя ожидать от конвергенции сетей, следует потихоньку «въезжать» в соответствующие технологии.

В этом посте захотелось поговорить о внутренней архитектуре конвергентного оборудования, предлагаемого Brocade, на примере платы FCOE10-24 для директоров DCX. Коммутатор Brocade 8000 устроен практически так же, с единственным принципиальным отличием: его «Core» функциональность и нативные FC порты находятся не на отдельных платах, а помещены в единый корпус коммутатора. С новой линейкой VDX я пока знаком понаслышке, так что напишу о ней, когда разберусь.

Итак, начнем сразу с ограничений использования. В одном коммутаторе не может использоваться более 4x FCOE10-24 (FOS v6.4.1_fcoe). Ни в коем случае нельзя соседствовать ни с кем, кроме обычных 16, 32 и 48-портовых FC модулей. Никаких FA, FR или FX,а так же FC8-64 модулей! В качестве оконечных устройств допускается применять CNA от Brocade, Emulex или Qlogic, а также FC и нативные FCoE интерфейсы дисковых массивов.

Интересное ограничение касается количества Fibre Channel ISL hops. Их не должно быть больше 3x. С точки зрения best practice так было рекомендовано всегда, но в данном случае присутствует жесткое “not supported”.

На платах расположены 24x порта 10GE. Для использования FCoE и CEE никаких дополнительных лицензий не требуется, только железо.

По доброй традиции можно применять только Brocade-branded SFP+. FCoE, конечно, ходит только на короткие расстояния, а LR SFP предназначены только для сетевого трафика. Медные twinax cables использовать нельзя. Они подходят только для 8000 коммутаторов.

Тип SFP	Тип оптического кабеля	Максимальная длина
SFP+ SR (Short Reach)	Multi Mode	33 м (OM1) 82 м (OM2) 300 м (OM3) 380 м (OM4)
SFP+ LR (Long  Reach)	Single Mode	2,5 км (трафик CEE) 10 км (трафик Ethernet)

С точки зрения внутренней архитектуры, FCOE10-24 можно рассматривать, как два объединенных коммутатора. ASIC Anvil отвечает за передачу CEE, а 8Gbps Condor2 за FC трафик. Оба они используют способ коммутации Cut-through.

Плата построена на базе 3x чипов Anvil. Каждый из них отвечает за группу из 8x TE портов (Ten gigabit Ethernet). ASICs всех плат в DCX связаны друг с другом и логически представляют из себя единый коммутатор, обрабатывающий весь Ethernet и CEE трафик. Anvil также отвечает и за работу протокола FIP (FCoE Initialization Protocol) и распознав FCoE, перенаправляет трафик на FPGAs Zeus.

Zeus используется как переходник для связи Anvil-Condor2 и обеспечивает инкапсуляцию / декапсуляцию FCoE фреймов. Он также отвечает за предоставление FPMA (Fabric Provided MAC Address), которые нужны для корректной маршрутизации фреймов FCoE в сети Ethernet.

Весь FC трафик обрабатывается единственным ASIC Condor2. Для представления FCoE портов в FC фабрике он формирует виртуальные VF порты (Virtual Fabric Ports). Для передачи данных на FC платы, ASIC Condor2 соединен с ASICs обоих Core blades.

Давайте рассмотрим весь путь прохождения фреймов. Когда CEE порт получает фрейм FCoE, он адресует его “своему” ASIC Anvil, который, в свою очередь перенаправляет данные для декапсуляции на Zeus. Далее данные передаются на Condor2. Каждому физическому TE порту может соответствовать только один виртуальный VE порт (и наоборот). В примере на рисунке, TE порт 23 смаплен на VF порт 23.
После этого данные уже путешествуют по протоколу FC и, пройдя backplain, уходят на ASICs, находящиеся на Core Blades.

Интересный нюанс. В каналах Anvil-Zeus трафик кодируется 64b/66b, а в Zeus-Condor2 используется 8b/10b. Каждому транку от Zeus на ASIC Condor2 выделяется 74x буферных кредита.

Группа из 8x TE портов может в максимуме получить до 80Gbps. Однако, суммарная пропускная способность каналов Anvil-Zeus ограничена всего 20Gbps. Внутренние пути Zeus-Condor2 представляют собой два транка по 16Gbps, но для того, чтобы соответствовать потоку данных с Anvil, пропускная способность снижена до 10Gbps.

В итоге, группа из 8x портов может использовать до 20Gbps внутренней пропускной способности платы. Простая арифметика дает нам переподписку 4:1.
Для более эффективного распределения нагрузки при подключении оконечных устройств к плате рекомендуется придерживаться “четверок” портов, т. .е подключаться в следующей последовательности:

• 0, 4, 8, 12, 16, 20;
• 1, 5, 9, 13, 17, 21
• 2, 6, 10, 14, 18, 22
• 3, 7, 11, 15, 19, 23

Теперь поговорим об CEE трафике. Мы уже знаем, что все ASICs Anvil объединены в единый Ethernet коммутатор. Трафик, который не является FCoE и предназначенный порту, находящемуся на том же самом Anvil коммутируется локально, не выходя наружу ASIC.

Если же порт назначения находится на соседнем Anvil или другой плате, то он, минуя Zeus и Condor2, по отдельным каналам перенаправляется на ASIC одного из Core blades и далее к Anvil назначения.

Каждый чип Anvil подключен к Core Blades посредством двух каналов 4x 8Gbps (итого 64Gbps). Соответственно, переподписка Ethernet трафика равна 80:64. Задержки передачи очень малы и не превышают 5 мкс.

Вот такая штуковина… :)