Ненадёжный Ethernet

В продолжение предыдущей статьи "Ethernet & FC ^[1]", хотел бы дать конкретные рекомендации по оптимизации Ethernet сети для работы с СХД NetApp FAS. Хотя, полагаю, многие вещи описанные здесь могут быть полезны и для других решений.

Не надёжный Ethernet ^[2]

Для тех, кто сильно сомневается в «надёжности» Ethernet. Не то чтобы хочу переубедить тотально переходить с FC8G на 10GBE, но хочу убрать некий ареол недоверия и непонимания технологии. Любой технический специалист должен всегда подходить к вопросу рационально и с «холодной головой». В тоже время заявления о том, что «Ethernet теряет фреймы» сложно назвать «не предвзятым подходом» и «не субъективным мышлением». Предлагаю рассмотреть откуда же взялось это устойчивое мнение о ненадёжности Ethernet, чтобы или развенчать все сомнения или их подтвердить имея на то конкретные обоснования.
Итак началось всё с рождения стандарта, когда Ethernet был 10МБит/с который использовал разделяемую среду коаксиального кабеля. При этом передача информации была «полудуплексная», т.е. в один момент время могла осуществляться одним узлом или передача или приём информации. Чем больше узлов сети в одном таком домене, тем больше было коллизий усугубляя ситуацию «полудуплексностью», здесь действительно терялись фреймы. Потом Ethernet шагнул дальше начал использовать витую пару дав задел на будущее, но глупые бриджи точно также объединяли все узлы сети в один домен коллизии и ситуация по сути не изменилась. Появились умные устройства, с гордым названием «коммутаторы», они не просто дублировали фреймы с одного своего порта на другой, они залазили внутрь фрейма и запоминали адреса и порты откуда фреймы приходили и передавали их только на порт получателя. И всё было бы хорошо, но коллизии по-прежнему в каком-то виде остались даже в 100МБит/с сетях, не смотря на то что домен коллизии дробился и сводился только к узлу с портом коммутатора, которые в однодуплексном режиме «натыкались» на коллизии когда пытались одновременно отослать друг-другу свой фрейм. То что произошло дальше — появилась «дуплексность», т.е. каждый узел мог одновременно и принимать и передавать фреймы по разным линкам: две пары RX и TX для узала и две для коммутатора. В 1Nexus ^[3] коммутаторов для ЦОД. Протокол TRILL и FabricPath, которые просто определяет назначение нового поля hop count в Ethernet фрейме по аналогии с полем time to live в IP пакете для предотвращения закольцовок, а также некоторых других функций «заимствованных» у IP избавив таким образом Ethernet от последних двух детских болезней.

Jumbo Frame ^[4]

В случае использования протоколов Maximum Transmission Unit (MTU). Мифы и рифы ^[5].

FlowControl ^[6]

Настройки flowcontrol должны соответствовать для обоих: портов СХД и подключённых к ним портов свича. Другими словами если flowcontrol на портах СХД установлен в none, то и на свиче flowcontrol должен быть установлен в off и наоборот. Другой пример: если СХД отправляет flowcontrol send, то свитч должен обязательно быть настроен для их приёма (flowcontrol receive on). Не соответствие настроек flowcontrol приводит к разрыву установленных сессий протоколов, к примеру CIFS или iSCSI, связь будет присутствовать, но из-за постоянных разрывов сессий будет работать очень медленно во время увеличения нагрузки на линк, а во время небольших нагрузок проблема проявляться не будет вовсе.

• Общее правило гласит по возможности не включать flowcontrol, TR-3428 ^[7].
• Для 10GB сетей крайне не рекомендуется включать flowcontrol.
• Для сетей 1GB можно включать flowcontrol (в качестве исключения из правила): хранилище отсылает управление потоком, а свитч принимает — на СХД устанавливать flowcontrol в значение send, а на свитче в значение Desired (или send/tx off & receive/rx on).
• Для 100 MB сетей (в качестве исключения из правила) можно включать flowcontrol на приём и передачу на обоих: хранилище и свитч отсылают и принимают команды управления потоком.
• Тем, кому интересно почему такие рекомендации, вам сюда ^[8].
• Дополнительно смотри 3802 ^[9]
• Примеры настройки хранилища ^[10] и свичий ^[11] можно посмотреть в соответствующих статьях.

Spanning Tree Protocol ^[12]

В случае использования NetApp с «классическим Ethernet» (т.е. Ethernet который так сказать «не уровня „Datacenter“) крайне рекомендуется включить TR-3749 ^[13]. Ethernet сети уровня „Datacenter“ вообще не нуждаются в Spanning Tree, примером такого оборудования могут служить коммутаторы Cisco серии Nexus с технологией vPC.

Converged Network ^[14]

Учитывая „универсальность“ 10выгодно отличает протокол и коммутаторы ^[1] от FC таким образом предоставляя возможность „манёвра“ и сохранения инвестиций в случае изменения бизнес потребностей.

FC8 vs 10GBE: iSCSI, CIFS, NFS ^[15]

Внутренние тестирования СХД NetApp (у других вендоров СХД эта ситуация может отличаться) FC8G и 10GBE iSCSI, CIFS и NFS показывают практически одинаковую производительность и латенси, характерным для OLTP и виртуализации серверов и десктопов, т.е. для нагрузок с мелкими блоками и случайным чтением записью.
Рекомендую ознакомится со стаьёй описывающей сходства, отличия и перспективы Ethernet & FC ^[1].

В случае когда инфраструктура заказчика подразумевает два коммутатора, то можно говорить об одинаковой сложности настройки как Wireshark ^[16]'ом трафик не „послушаешь“.

Современные конвергентные коммутаторы, такие как Cisco Nexus 5500 способны коммутировать как трафик Ethernet так и FC позволяя иметь большую гибкость в будущем благодаря решению „два-в-одном“.

LACP ^[17]

Также не забываете о возможности агрегации портов при помощи EtherChannel LACP. Нужно также понимать, что агрегация не объединяет волшебным образом Ethernet порты, а всего лишь распределяет (балансирует) трафик между ними, другими словами два агрегированных 10GBE порта далеко не всегда „дотягивают“ до 20GBE. Здесь стоит отметить, что в зависимости от того, находится ли СХД в отдельной IP подсети от хостов, нужно выбирать правильный метод балансировки. В случае когда СХД находится в отдельной подсети от хостов нельзя выбирать балансировку по MAC (дестинейшина), так как он будет всегда один и тот-же — MAC адрес шлюза. В случае когда хостов меньше, чем количество агрегированных линков на СХД, балансировка работает не оптимальным образом в виду не совершенства и ограничений сетевых алгоритмов балансировки нагрузки. И наоборот: чем больше узлов сети используют агрегированный линк и чем „правильнее“ подобран алгоритм балансировки, тем больше максимальная пропускная способность агрегированного линка приближается к сумме пропускных способностей всех линков.
Документ TR-3749 ^[18] описывает нюансы настройки VMWare ESXi с СХД NetApp и коммутаторами Cisco.

vif create lacp <vif name> -b ip {interface list}

s3(config)#int port-channel1
s3(config-if)#description LACP multimode VIF for netapp1
s3(config-if)#int gi0/23
s3(config-if)#channel-protocol lacp
s3(config-if)#channel-group 1 mode active

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

Замечания по ошибкам в тексте и предложения прошу направлять в ЛС.

Автор: bbk

Источник ^[19]