Функция flow control в медиаконвертерах
Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.
Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).
Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.
IBM Redbook «Introduction to SAN and System Networking»
Начало
По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.
FC-0 — уровень физических интерфейсов и носителей. Описывает физическую среду: кабели, коннекторы, HBA, трансиверы, электрические и оптические параметры.
- Fibre Channel Protocol for SCSI-3 (SCSI-FCP) — проброс SCSI
- Fibre Channel Link Encapsulation (FC-LE) — проброс TCP/IP
А теперь подробнее об этих и других непонятных словосочетаниях. В данной статье рассмотрим только нижние три уровня, как наиболее значимые при создании и управлении инфраструктурой FC SAN.
Отдельно хочу упомянуть про такой термин как тёмная оптика (dark fiber). Сей термин не значит, что она как-то специальным образом тонирована. Это просто выделенные оптические линии связи, как правило, для связи на больших расстояниях (между городами или далеко отстоящими зданиями), которые берутся в аренду, и для использования которых не требуется дополнительное оборудования усиления сигнала (его обеспечивает владелец). Однако, так как это просто оптический кабель, отданный в ваше полновластное распоряжение, до тех пор пока вы не пустите по нему свой световой сигнал, он остаётся «тёмным».
ASIC (аббревиатура от англ. application-specific integrated circuit, «интегральная схема специального назначения») — интегральная схема, специализированная для решения конкретной задачи. В отличие от интегральных схем общего назначения, специализированные интегральные схемы применяются в конкретном устройстве и выполняют строго ограниченные функции, характерные только для данного устройства; вследствие этого выполнение функций происходит быстрее и, в конечном счёте, дешевле. Примером ASIC может являться микросхема, разработанная исключительно для управления мобильным телефоном, микросхемы аппаратного кодирования/декодирования аудио- и видео-сигналов (сигнальные процессоры).
- Encoder / Decoder — обеспечивает кодирование каждых 8 бит передаваемых данных в 10-битное представление. И декодирование обратно принимаемых данных.
- SERDES (Serializer / Deserializer) — преобразует параллельный поток 10-битных порций данных в последовательный поток 10-битных порций данных.
- Transceiver — преобразует электрические импульсы в световые сигналы.
Transceivers, трансиверы или SFP — в случае FC-коммутаторов это отдельные модули, необходимые для подключения кабеля к порту. Различаются на коротковолновые (Short Wave, SW, SX) и длинноволновые (Long Wave, LW, LX). LW-трансиверы совместимы с многомодовым и одномодовым волокном. SW-трансиверы — только с многомодовым. И к тем и к другим кабель подключается разъёмом LC.
Есть ещё SFP xWDM (Wavelenght Division Multiplexing), предназначенные для передачи данных из нескольких источников на дальние расстояния единым световым пучком. Для подключения кабеля к ним используется разъём SC.
8/10 и 64/66
Первое, что происходит на этом уровне — кодирование / декодирование информации. Это довольно мудрёный процесс, в ходе которого каждые 8 бит поступающей информации преобразуются в 10-битное представление. Делается это с целью повышения контроля целостности данных, отделения данных от служебных сигналов и возможности восстановления тактового сигнала из потока данных (сохранение баланса нулей и единиц).
Это ведёт к заметному снижению полезной пропускной способности, ибо как можно подсчитать, 20% потока данных является избыточной служебной информацией. А ведь кроме всего прочего, немалую часть этого потока может занимать служебный трафик.
Однако хорошая новость в том, что кодирование 8/10 используется в оборудовании 1G, 2G, 4G и 8G. В части реализаций 10G и начиная с 16G кодирование осуществляется по принципу 64/66, что существенно увеличивает полезную нагрузку (до 97% против 80% в случае 8/10).
Ordered sets
- Разделители фреймов (Start-of-Frame, SOF и End-of-Frame, EOF).
- Два базовых сигнала — IDLE (порт готов принимать или передавать данные) и R_RDY (receiver ready — порт освободил буфер для приёма очередной порции данных)
- Базовые последовательности (primitive sequences):
- NOS (Not Operational) — порт обнаружил разрыв / отсутствие соединения
- OLS (Offline State) — порт инициирует установление соединения, или порт получил NOS, или порт переходит в состояние off-line
- LR (Link Reset) — инициализация сброса соединения. Отправляется в случае получения OLS или каких-то ошибок приёма-передачи (как правило, на уровне Flow Control). Отправивший порт очищает свои буферы и их счётчики
- LRR (Link Reset Response) — ответ на LR. Отправивший порт очищает свои буферы и их счётчики
Инициализация соединения (Link initialization)
При установлении физического соединения между портами A и B, между ними происходит следующий «обмен веществ»:
Фреймы (Кадры, Frames)
- SoF — 4 байта (1 tw) — идентификатор начала фрейма.
- Header — 24 байта (6 tw) — заголовок. Содержит такую информацию как адрес источника и приёмника, тип фрейма (FT-0 — управляющий или FT-1 — данные), номер последовательности и порядковый номер фрейма в ней и прочая служебно-контрольная информация.
- Data — 0-2112 байт (0-528 tw) — непосредственно данные (например, SCSI-команды).
- CRC — 4 байта (1 tw) — контрольная сумма.
- EoF — 4 байта (1 tw) — идентификатор конца фрейма.
Промежутки между фреймами заполняются специальными «заполняющими словами» — fill word. Как правило, это IDLE, хотя начиная с FC 8G было стандартизовано использование ARB(FF) вместо IDLE, в целях снижения электрических помех в медном оборудовании (но по-умолчанию коммутаторами используется IDLE).
Последовательности (Sequences)
Чаще всего источник стремится передать приёмнику гораздо больше информации, чем 2112 байт (максимальный объём данных одного фрейма). В этом случае информация разбивается на несколько фреймов, а набор этих фреймов называется последовательностью (sequence). Чтобы в логическую последовательность фреймов не вклинилось что-то лишнее при параллельной передаче, заголовок каждого фрейма имеет поля SEQ_ID (идентификатор последовательности) и SEQ_CNT (номер фрейма в последовательности).
Обмен (Exchange)
Одна или несколько последовательностей, отвечающих за какую-то одиночную операцию, называется обменом. Источник и приёмник могут иметь несколько параллельных обменов, но каждый обмен в единицу времени может содержать только одну последовательность. Пример обмена: инициатор запрашивает данные (последовательность 1), таргет возвращает данные инициатору (последовательность 2) и затем сообщает статус (последовательность 3). В этот набор последовательностей не может вклиниться какой-то посторонний набор фреймов.
Для контроля этого процесса заголовок каждого фрейма включает поля OX_ID (Originator Exchange ID — заполняется инициатором обмена) и RX_ID (Responder Exchange ID — заполняется получателем в ответных фреймах, путём копирования значения OX_ID).
Классы обслуживания (Classes of Services)
Различные приложения предъявляют разные требования к уровню сервиса, гарантии доставки, продолжительности соединения и пропускной способности. Некоторым приложениям требуется гарантированная пропускная способность в течение их работы (бэкап). Другие имеют переменную активность и не требуют постоянной гарантированной пропускной способности канала, но им нужно подтверждение в получении каждого отправленного пакета. Для удовлетворения таких потребностей и обеспечения гибкости, FC определяет следующие 6 классов обслуживания.
Class 1
Для этого класса устанавливается выделенное соединение, которое резервирует максимальную полосу пропускания между двумя устройствами. Требует подтверждения о получении. Требует чтобы фреймы попадали на приёмник в том же порядке, что вышли из источника. Ввиду того, что не даёт другим устройствам использовать среду передачи, используется крайне редко.
Class 2
Без постоянного соединения, но с подтверждением доставки. Не требует соответствия порядка отправленных и доставленных фреймов, так что они могут проходить через фабрику разными путями. Менее требователен к ресурсам, чем класс 1, но подтверждение доставки приводит к повышенной утилизации пропускной способности.
Class 3
Без постоянного соединения и без подтверждения доставки. Самый оптимальный с точки зрения использования ресурсов фабрики, но предполагает, что протоколы верхних уровней смогут собрать фреймы в нужном порядке и перезапросить передачу пропавших фреймов. Наиболее часто используемый.
Class 4
Требует постоянного соединения, подтверждение и порядок фреймов как и класс 1. Главное отличие — он резервирует не всю полосу пропускания, а только её часть. Это гарантирует определённое QoS. Подходит для мультимедиа и Enterprise-приложений, требующих гарантированного качества соединения.
Class 5
Ещё до конца не описан и не включен в стандарт. Предварительно, класс, не требующий соединения, но требующий немедленной доставки данных по мере их появления, без буферизации на устройствах.
Class 6
Вариант класса 1, но мультикастовый. То есть от одного порта к нескольким источникам.
Class F
Класс F определён в стандарте FC-SW для использования в межкоммутаторных соединениях (Interswitch Link, ISL). Это сервис без постоянного соединения с уведомлениями о сбое доставки, использующийся для контроля, управления и конфигурирования фабрики. Принцип похож на класс 2, но тот используется для взаимодейтсвия между N-портами (порты нод), а класс F — для общения E-портов (межкоммутаторных).
Flow Control
В целях предотвращения ситуации, когда отправитель перегрузит получателя избыточным количеством фреймов так, что они начнут отбрасываться получателем, FC использует механизмы управления потоком передаваемых данных (Flow Control). Их два — Buffer-to-Buffer flow control и End-to-End flow control. Их использование регламентируется классом обслуживания. Например, класс 1 использует только механизм End-to-End, класс 3 — Buffer-to-Buffer, а класс 2 — оба эти механизма.
Buffer-to-Buffer flow control
Принцип технологии — кредит в каждый дом отправка любого фрейма должна быть обеспечена наличием кредита на отправку.
Все поступающие на вход порта фреймы помещаются в специальную очередь — буферы. Количество этих буферов определяется физическими характеристиками порта. Один буфер (место в очереди) соответствует одному кредиту. Каждый порт имеет два счётчика кредитов:
TX BB_Credit — счётчик кредитов передачи. После отправки каждого фрейма, уменьшается на 1. Если значение счётчика стало равным нулю — передача невозможна. Как только от порта-приёмника получено R_RDY, счётчик увеличивается на 1.
RX BB_Credit — счётчик кредитов приёма. Как только фрейм принят и помещён в буфер, уменьшается на 1. Когда фрейм обрабатывается или пересылается дальше, счётчик увеличивается на 1, а отправителю отправляется R_RDY. Если значение счётчика падает до 0, то в принципе, приём новых фреймов должен быть прекращён. На практике, из-за ошибок синхронизации кредитов может возникнуть ситуация, что источник прислал ещё один-несколько фреймов уже после того как RX BB_credit стал равен нулю. Данная ситуация называется buffer overflow. В большинстве реализаций порт обрабатывает такие ситуации «по-доброму» — за счёт резервных буферов. Хотя некоторое оборудование в таких случаях может сынициировать Link Reset.
Отсюда исходит сильное влияние расстояния между портами на производительность. Чем выше расстояние и больше пропускная способность, тем больше фреймов будет отправлено (читай кредитов передачи потрачено) ещё до того как получатель получит хотя бы первый. Ситуацию облегчает особенность архитектуры FC-коммутаторов. Дело в том, что количество буферов не закреплено жёстко за каждым портом (кроме восьми обязательных), а является общим для всех. И в случае определения «дальних линков» (автоматически или вручную) количество выделяемых коммутатором буферов для этого порта увеличивается. Другой плюс общей памяти — не требуется гонять буферы от одного порта к другому внутри коммутатора.
End-to-End flow control
Конец
Изначально мне казалось, что статья будет раза в два меньше, но в ходе написания всплыло много деталей, без которых счастье казалось не полным. Ещё кучу вещей, которые хотелось бы осветить, пришлось пока отбросить — процесс написания грозил стать бесконечным. Если у кого-то возникнут замечания, предложения и пожелания к тому, про что ещё стоит написать, буду признателен. И спасибо всем, кто дочитал до этого места.
Были использованы материалы из следующих источников:
IBM Redbook «Introduction to SAN and System Networking»
EMC «Network Storage Concepts and Protocols»
Brocade «SAN Fabric Administration Best Practices Guide»
Управление потоком IEEE 802.3x обеспечивает функции управления трафиком для режима полного дуплекса. Управление потоком позволяет улучшить работу сетевого адаптера в режиме полного дуплекса с коммутатором. При работе в полном дуплексе (при этом требуется непосредственное подключение к коммутатору) и при угрозе переполнения буфера данных коммутатора, сетевой адаптер получит специальный кадр паузы. Последующий промежуток времени защищает буфер от переполнения и предотвращает потерю данных. Эта технология может улучшить общую производительность сети, предотвращает потерю данных и помогает достичь оптимальной производительности в сети.
По умолчанию эта опция отключенна. Отсюда у меня возникает ряд вопросов.
1. Стоит ли её включать и что это мне даст?
2. Flow Control работает со всеми сетевыми картами или только с теми что поддерживают этот режим.
3. Работает ли Flow Control между свичами (управляемый-неуправляемый)?
4. Какие негативные возможны последствия от включения этой опции? Ведь не зря она отключенна по умолчанию.
1) По сути Flow Control нужен в том случае если устройства на одном линке имеют разную произвиодительноть по приёму передаче кадров. Посылка стопового сигнала помогает избежпть потерь кадров.
2) Flow Control должен быть включён или выключен на обоих концах линка, т.е. сетевая карта конечно тоже должна поддерживать эту функцию и причём если на свитче она включена на сетвой карте она тоже должна быть включена.
3) Между управляемым и неуправляемым тоже может работать.
4) Последствия могут быть только если есть несоотвествие выбора режима работы функции на обоих концах линка.
5) На некоторых сериях свитчей например DES-30XX для корректной работы функции Bandwidth Control функция Flow control должна быть включена.
Ненадёжный Ethernet
Jumbo Frame
В случае использования протоколов NFS , iSCSI , CIFS рекомендуется по возможности включать jumbo frame, на коммутаторах и хостах. СХД NetApp поддерживает на данный момент размер MTU 9000, что пока что является максимальным значением для Ethernet 10GB. В этом случае jumbo frame должны быть включены на всём пути следования Ethernet фреймов: от источника до получателя. К сожалению не во всех коммутаторах и не на всех сетевых адаптерах хостов поддерживается «максимальный» на данный момент MTU , так к примену некоторые блейд-шасси HP с серверами и встроенными 10GB коммутаторами поддерживают максимум 8000 MTU , для таких случаев на стороне СХД необходимо подбирать наиболее подходящее значение MTU . Так как есть некотарая путаница в том, что такое MTU , есть трудности с пониманием какое значение MTU нужно настроить. Так к примеру для нормальной работы СХД NetApp с установленным значением MTU 9000 на Ethernet интерфейсе будет «нормально» работать со свичами у которы значение MTU установлено в одно из значений: 9000 (Catalyst 2970/2960/3750/3560 Series), 9198 (Catalyst 3850), 9216 (Cisco Nexus 3000/5000/7000/9000, Catalyst 6000/6500 / Cisco 7600 OSR Series), на других это значение вообще должно быть 9252. Как правило, установив MTU на свиче в максимально допустимое значение (выше или равно 9000), всё будет работать. Для разъяснения, рекомендую прочесть соответствующую статью Maximum Transmission Unit (MTU). Мифы и рифы.
Jumbo Frames в Cisco UCS
Выполняем инастройку из командной строки на каждом Fabric Interconnect:
В настройках UCS Manager при работе с Ethernet настраиваем MTU во вкладке «Lan > Lan Cloud > QoS System Class», прописываем MTU одному выбранному классу.Потом создаём «QoS политику»
Создаём vNIC template
Привязываем к сетевому интерфейсу сервера.
FlowControl
- Общее правило гласит по возможности не включать flowcontrol, TR-3428.
- Для 10GB сетей крайне не рекомендуется включать flowcontrol.
- Для сетей 1GB можно включать flowcontrol (в качестве исключения из правила): хранилище отсылает управление потоком, а свитч принимает — на СХД устанавливать flowcontrol в значение send, а на свитче в значение Desired (или send/tx off & receive/rx on).
- Для 100 MB сетей (в качестве исключения из правила) можно включать flowcontrolна приём и передачу на обоих: хранилище и свитч отсылают и принимают команды управления потоком.
- Тем, кому интересно почему такие рекомендации, вам сюда.
- Дополнительно смотри TR -3802
- Примеры настройки хранилища и свичий можно посмотреть в соответствующих статьях.
Spanning Tree Protocol
В случае использования NetApp с «классическим Ethernet» (т.е. Ethernet который так сказать «не уровня „Datacenter“) крайне рекомендуется включить RSTP , а Ethernet порты, в которые подключены конечные узлы (СХД и хосты) настроить с включенным режимом portfast, TR-3749. Ethernet сети уровня „Datacenter“ вообще не нуждаются в Spanning Tree, примером такого оборудования могут служить коммутаторы Cisco серии Nexus с технологией vPC .
Converged Network
FC8 vs 10GBE: iSCSI, CIFS, NFS
Современные конвергентные коммутаторы, такие как Cisco Nexus 5500 способны коммутировать как трафик Ethernet так и FC позволяя иметь большую гибкость в будущем благодаря решению „два-в-одном“.
Также не забываете о возможности агрегации портов при помощи EtherChannel LACP . Нужно также понимать, что агрегация не объединяет волшебным образом Ethernet порты, а всего лишь распределяет (балансирует) трафик между ними, другими словами два агрегированных 10GBE порта далеко не всегда „дотягивают“ до 20GBE . Здесь стоит отметить, что в зависимости от того, находится ли СХД в отдельной IP подсети от хостов, нужно выбирать правильный метод балансировки. В случае когда СХД находится в отдельной подсети от хостов нельзя выбирать балансировку по MAC (дестинейшина), так как он будет всегда один и тот-же — MAC адрес шлюза. В случае когда хостов меньше, чем количество агрегированных линков на СХД , балансировка работает не оптимальным образом в виду не совершенства и ограничений сетевых алгоритмов балансировки нагрузки. И наоборот: чем больше узлов сети используют агрегированный линк и чем „правильнее“ подобран алгоритм балансировки, тем больше максимальная пропускная способность агрегированного линка приближается к сумме пропускных способностей всех линков. Подробнее про белансировку LACP смотрите в статье „Агрегация каналов и балансирова трафика по IP“.
Документ TR-3749 описывает нюансы настройки VMWare ESXi с СХД NetApp и коммутаторами Cisco.
на NetApp 7-Mode
на NetApp Clustered ONTAP
Обратите внимание, portfast (spanning-tree port type edge) должен быть настроен ДО того, как будет подключён NetApp!
На коммутаторе Cisco Catalyst:
На коммутаторе Cisco Nexus 5000:
Уверен, что со временем мне будет что добавить в эту статью по оптимизации сети, спустя время, так что заглядывайте сюда время от времени.
Замечания по ошибкам в тексте и предложения прошу направлять в ЛС .
На портах cisco catalyst счётчики приёма pause frame растут (судя по выводу sh int gx/xx flowcontrol ).
Объясните, пожалуйста, в чём именно и как должен проявиться эффект от включения Flow Control на портах?
После влючения Flow Control при переполнении очереди на порту будет послан pause frame и устройство с другой стороны линка притормозит передачу. В результате - получите более равномерную нагрузку на порту.
т.е. более плавный график нагрузки на порту? Без скачков?
Да. И более управляемый - так как передатчик будет останавливать передачу при переполнении порта приемника - то процессор на приемнике не будет перегружаться.
Это все относится к ситуации переполнения очередей на порту, если нагрузка ниже - то эффекта не будет никакого
Ясно. Спасибо! А можете дать какие-нибудь общие рекомендации по размещению данной функции (Access Layer, Destribution Layer, Core Layer) в сети?
У нас в сети это включено на 10Г линках на уровне дистрибуции и ядра. На уровне access не включали. На уровне доступа не может быть полной нагрузки на порт ;)
Читайте также: