Давайте сравним методы контроля передачи данных в Fibre Channel и 10GE. Основная из задача – обеспечивать временную остановку передачи данных в случае нехватки входящих буферов портов-получателей. Напомню, что в FC используется механизм контроля счетчиков буферных кредитов. Объединяясь в фабрику, порты коммутаторов обмениваются информацией об общем количестве входных буферов и выставляют соответствующие значения счетчиков буферных кредитов (BB-credits). Отправив пакет, порт декрементирует свой счетчик. Если он обнуляется, отправитель должен остановить передачу. Порт-получатель в свою очередь, обязан явно сообщать о каждой освободившейся ячейке буфера посылкой слова-примитива Receiver Ready (R_RDY), Получив R_RDY, порт получатель инктеменитует значение BB credits.
Такой механизм гарантирует, что порты отправитель и получатель всегда имеют точную информацию о количестве свободных буферов на другом конце линка.
Очень важно отметить, что R_RDY является не FC фреймом (с заголовком, payload, CRC и т. д.), а 4byte (40bit) словом, т. е. объектом минимального размера, допустим для передачи по протоколу Fibre Channel. Соответственно, с точки зрения утилизации каналов накладные расходы контроля передачи данных практически не заметны.
Однако у каждой медали есть обратная сторона. Время между отправкой фрейма и получением сигнала R_RDY сильно зависит от расстояния между портами. Чем больше расстояние, тем дольше отправитель должен ждать инкрементации BB Credits. А это, в случае нехватки кредитов, приводит к задержкам передачи данных и падению загрузки линка.
На приведенном графике значение длины линка, при котором начинается падение утилизации канала, зависит от скорости передачи (Transfer Rate) и количества входных буферов. Увеличение количества доступных входных буферов, приводит к тому, счетчик буферных кредитов обнулится на больших расстояниях. Соответственно, точка перегиба на графике сдвигается вправо.
Давайте теперь рассмотрим протокол Ethernet. Он не имеет примитивов и предусматривает передачу данных в сети только фреймами. Минимальный размер фрейма 64bytes. Если бы в этом протоколе контроль передачи данных был реализован таким же образом, как и в FC, он был бы в 16 раз менее эффективным. Поэтому и был выбран другой метод. Вместо того чтобы постоянно сообщать о количестве свободных буферов, устройства в Ethernet явно сообщают только о событии, когда их не хватает. Таким образом, существенно экономится пропускная способность каналов.
Главным недостатком этого механизма является то, что как и в Fibre Channel, общая эффективность контроля передачи данных заметно падает с увеличением длины линка. Утилизация длинных линков становится низкой.
Для полной загрузки линков на больших расстояниях необходимо либо отключать механизм контроля передачи, либо увеличивать количество входных буферов в коммутаторах, соответствующим образом сдвинув пороговые значения.
На самом деле это выбор без выбора, ведь с отключением Flow Control появится вероятность потери фреймов, что для трафика FCoE совершенно не приемлемо. Поэтому производители увеличивают количество буферных ячеек. На данный момент Cisco повысила максимальную длину линков между своими коммутаторами с 300м. до 3км. (NX-OS 5.0(2)N1.1).
- Nexus 55xx - Nexus 55xx – 3км.
- Nexus 50x0 - Nexus 50x0 - 3 км.
- Nexus 50x0 - Nexus 55xx - 3 км.
- Nexus 55xx - Nexus 2232 – 300м.
- Nexus 50x0 - Nexus 2232 – 300м.
Brocade, вроде, пока ограничивает длину линков 300м.
Не понял последнего предложения: Brocade, вроде, пока ограничивает длину линков н 300 м.
ОтветитьУдалитьВсё же зависит от количесива выделенных буферов... Пожалуйста: берём 12 буферов и получаем рботающий линк FC 8G на 3 км. По аналогии дальше хоть на 100 км... Разве не так? К тому же на длинных линках очень важен не только механизм подтверждения получения, но и механизм восстановления пакетов в случае потерь в линии.
300м - имелось ввиду ограничение для FCoE.
ОтветитьУдалитьВ FC действительно можно играться с буферными кредитами, как вы сказали. Но кредиты это просто настройка. Количество буферов в ASIC жестко определоно его конструкцией. Например, Brocade 300 построен на чипе GoldenEye2. На все 24 порта доступны 676 (входных) буферов. По 8 буферов минимально зарезервировано для каждого порта. Остаются 484 буфера для длинных соединений. А этого для предложенных вами для примера 8G на 100км уже не хватит. Вернее, по грубой теоретической прикидке нужно 400, но на практике рекомендуется вводить коэффициент 1,5 или даже 2.
Flow Control это не межанизм подтверждения, как в TCP. R_RDY не подтверждает получения фрейма, он сигнализирует другой конец физического линка об освобождении одного (любого) из буферов.
Что же касается восстановления пакетов, то в FC такой механизм отсутствует! Если вы потеряли хотя бы один фрейм, заново надо передавать весь сиквенс. А он может достаточно большим. Именно для того, чтобы этого не случалось и придумана вся эта бодяга с Flow Control.