Ненадёжный Ethernet

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


    Ненадёжный Ethernet

    Для тех, кто сильно сомневается в «надёжности» Ethernet. Не то чтобы хочу переубедить тотально переходить с FC8G на 10GBE, но хочу убрать некий ареол недоверия и непонимания технологии. Любой технический специалист должен всегда подходить к вопросу рационально и с «холодной головой». В тоже время заявления о том, что «Ethernet теряет фреймы» сложно назвать «не предвзятым подходом» и «не субъективным мышлением». Предлагаю рассмотреть откуда же взялось это устойчивое мнение о ненадёжности Ethernet, чтобы или развенчать все сомнения или их подтвердить имея на то конкретные обоснования.
    Итак началось всё с рождения стандарта, когда Ethernet был 10МБит/с который использовал разделяемую среду коаксиального кабеля. При этом передача информации была «полудуплексная», т.е. в один момент время могла осуществляться одним узлом или передача или приём информации. Чем больше узлов сети в одном таком домене, тем больше было коллизий усугубляя ситуацию «полудуплексностью», здесь действительно терялись фреймы. Потом Ethernet шагнул дальше начал использовать витую пару дав задел на будущее, но глупые хабы точно также объединяли все узлы сети в один домен коллизии и ситуация по сути не изменилась. Появились умные устройства, с гордым названием «коммутаторы», они не просто дублировали фреймы с одного своего порта на другой, они залазили внутрь фрейма и запоминали адреса и порты откуда фреймы приходили и передавали их только на порт получателя. И всё было бы хорошо, но коллизии по-прежнему в каком-то виде остались даже в 100МБит/с сетях, не смотря на то что домен коллизии дробился и сводился только к узлу с портом коммутатора, которые в однодуплексном режиме «натыкались» на коллизии когда пытались одновременно отослать друг-другу свой фрейм. То что произошло дальше — появилась «дуплексность» (10BASE-T, IEEE 802.3i), т.е. каждый узел мог одновременно и принимать и передавать фреймы по разным линкам: две пары RX и TX для узала и две для коммутатора. В 1GBE полудуплексного режима больше вообще не существует. Что это значит? Коллизии пропали навсегда… Их больше нет. Осталось две детские болезни Ethernet, тесно связанные друг с другом это то, что коммутаторы при переполнении своего буфера могли «забывать» фреймы, а случалось это как правило из-за «закольцовок» (Ethernet Loop). Эти проблемы решили соответственно: 1) DCB дополнение для протокола Ethernet известное также как Lossless Ethernet — это набор протоколов козволяющих как и в случае FC не терять фреймы. 2) Просто добавили больше памяти в коммутаторы уровня ЦОД. 3) А сеть 10GBE и компания Cisco в частности шагнули дальше и предложили TRILL в своей линейке Nexus коммутаторов для ЦОД. Протокол TRILL и FabricPath, которые просто определяет назначение нового поля hop count в Ethernet фрейме по аналогии с полем time to live в IP пакете для предотвращения закольцовок, а также некоторых других функций «заимствованных» у IP, избавив таким образом 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:
    system jumbomtu 9216
    policy-map type network-qos jumbo
    class type network-qos class-default
    mtu 9216
    multi-cast-optimize
    exit
    system qos
    service-policy type network-qos jumbo
    exit
    copy run start
    


    Либо из GUI интерфейса UCS Manager
    В настройках UCS Manager при работе с Ethernet настраиваем MTU во вкладке «Lan > Lan Cloud > QoS System Class», прописываем MTU одному выбранному классу.

    Потом создаём «QoS политику»

    Создаём vNIC template

    Привязываем к сетевому интерфейсу сервера.



    FlowControl

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


    Не путать «Обычный» FlowControl с PFC (IEEE 802.1Qbb) для DCB (Lossless) Eternet.

    Spanning Tree Protocol

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

    Converged Network

    Учитывая „универсальность“ 10GBE, когда по одной физике могут ходить одновременно FCoE, NFS, CIFS, iSCSI, на ряду с применением таких технологий как vPC и LACP, а также простоту обслуживания Ethernet сетей выгодно отличает протокол и коммутаторы от FC таким образом предоставляя возможность „манёвра“ и сохранения инвестиций в случае изменения бизнес потребностей.

    FC8 vs 10GBE: iSCSI, CIFS, NFS

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

    В случае когда инфраструктура заказчика подразумевает два коммутатора, то можно говорить об одинаковой сложности настройки как SAN так и Ethernet сети. Но у многих заказчиков SAN сеть не сводится к двум SAN коммутаторам где „все видят всех“, на этом как правило, настройка далеко не заканчивается, в этом плане обслуживание Ethernet намного проще. Как правило SAN сети заказчиков это множество коммутаторов с избыточными линками и связями с удалёнными сайтами, что отнюдь не тривиально в обслуживании. И если что-то пойдёт не так, Wireshark'ом трафик не „послушаешь“.

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

    LACP

    Также не забываете о возможности агрегации портов при помощи EtherChannel LACP. Нужно также понимать, что агрегация не объединяет волшебным образом Ethernet порты, а всего лишь распределяет (балансирует) трафик между ними, другими словами два агрегированных 10GBE порта далеко не всегда „дотягивают“ до 20GBE. Здесь стоит отметить, что в зависимости от того, находится ли СХД в отдельной IP подсети от хостов, нужно выбирать правильный метод балансировки. В случае когда СХД находится в отдельной подсети от хостов нельзя выбирать балансировку по MAC (дестинейшина), так как он будет всегда один и тот-же — MAC адрес шлюза. В случае когда хостов меньше, чем количество агрегированных линков на СХД, балансировка работает не оптимальным образом в виду не совершенства и ограничений сетевых алгоритмов балансировки нагрузки. И наоборот: чем больше узлов сети используют агрегированный линк и чем „правильнее“ подобран алгоритм балансировки, тем больше максимальная пропускная способность агрегированного линка приближается к сумме пропускных способностей всех линков. Подробнее про белансировку LACP смотрите в статье „Агрегация каналов и балансирова трафика по IP“.
    Документ TR-3749 описывает нюансы настройки VMWare ESXi с СХД NetApp и коммутаторами Cisco.
    Пример настройки LACP
    на NetApp 7-Mode
    vif create lacp <vif name> -b ip {Port list}
    

    на NetApp Clustered ONTAP
    ifgrp create -node <node name> -ifgrp <vif name> -distr-func {mac | ip | sequential | port} -mode multimode_lacp 
    ifgrp add-port -node <node name> -ifgrp <vif name> -port {Port 1}
    ifgrp add-port -node <node name> -ifgrp <vif name> -port {Port 2}
    


    Обратите внимание, portfast (spanning-tree port type edge) должен быть настроен ДО того, как будет подключён NetApp!
    На коммутаторе Cisco Catalyst:
    cat(config)#interface gi0/23
    cat(config)#description NetApp e0a Trunk
    cat(config)#switchport mode trunk
    cat(config)#switchport trunk allowed vlan 10,20,30
    cat(config)#switchport trunk native vlan 123
    cat(config)#flowcontrol receive on
    cat(config)#no cdp enable
    cat(config)#spanning-tree guard loop
    cat(config)#!portfast must be configured before netapp connection
    cat(config)#spanning-tree portfast
    cat(config)#
    cat(config)#int port-channel1
    cat(config-if)#description LACP multimode VIF for netapp1
    cat(config-if)#int gi0/23
    cat(config-if)#channel-protocol lacp
    cat(config-if)#channel-group 1 mode active
    


    На коммутаторе Cisco Nexus 5000:
    n5k(config)#interface EthernetX/X/X
    n5k(config-if)#switchport mode trunk
    n5k(config-if)#switchport trunk allowed vlan XXX
    n5k(config-if)#spanning-tree port type edge
    n5k(config-if)#channel-group XX mode active
    n5k(config)#
    n5k(config)#interface port-channelXX
    n5k(config-if)#switchport mode trunk
    n5k(config-if)#switchport trunk allowed vlan XX
    n5k(config-if)#!portfast must be configured before netapp connection
    n5k(config-if)#spanning-tree port type edge
    


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

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

    Комментарии 24

      0
      А как на счет скорости отклика в такой реализации?
        0
        Скорость отклика от приложения до хранилища через езернет сеть как правило практически такая же как и в Fibre Channel, иногда такая-же, в случае использования соответствующих датацентровых свитчей. Разница как правило на столько не велика, что ею можно пренебречь. Но это касается нетапа и свичей DCB, о других решениях не могу ничего сказать.
          0
          Почти — это на сколько? Вы проводили тесты? Есть результаты?
          Так же можно попросить вас написать примерные модели для сравнения, где разница будет минимальна?
          И еще интересует вопрос разницы по цене.
          Вопросы задаю, так как присматриваюсь к данной технологии.
            0
            Да, нетап проводил тест для нагрузок баз данных и виртуализации, т.е. мелких блоков с случайной записью и порядка 70/30 R/W. Не уверен что могу их здесь выложить, так как такие документы нужно адекватно интерпретировать.
            Но для нетапа к примеру nfs на 10 гб должен давать одинаковые показатели латенси и iops по сравнению с fc8. Если это не так, то точно есть проблема с сетью.
            Могу сказать относительно латенси, что можно получить 0.5 мс (для этого нужен будет флеш) отклик для чтения и записи на езернет.
              0
              Относительно цены прошу обратиться к вашему локальному дистрибьютору или партнеру. Я технарь и работаю с технологиями а не ценами.
                +1
                Спасибо за ответ.
                +1
                Сравнение с FC не проводил т.к. сразу решили остановиться на 10GbE. Конфиг: 8 хостов, 2 свича, FAS2240-2 четырьмя шнурками в свичи. Пока нагрузка не начинает упираться в диски, задержки по чтению/записи 1-1.5мс на 600Gb SAS дисках. Флэшпула и Флэшкэша нет. Старый флэшевый сторадж выдавал 1.5-2мс задержки, но там стоимость гига была значительно выше, а надёжности никакой (1 голова, 1 сетевуха). Так что, считаю, что на обычных винтах разницу с FC уловить будет крайне сложно. Всё упирается в винты. Если же покупать взрослый флэшевый сторадж, то тут уже и FC не спасёт, нужен Infiniband.
            0
            Смысл всё это городить, когда потом контроллер застенчиво (с дебаг-приоритетом) пишет в логах что-то типа «запись идёт слишком долго, операция заняла больше 60с: 360» и делает чистой воды таймаут на подмонтированных томах (на самих томах нет — а вот в ожидающем ответа софте — вполне). При этом соседний контроллер считает, что всё зашибись и никакого тейковера не происходит.

            В ответ на претензию саппорт нетаппа говорит: «ой, но у вас не было perfdata на момент аварии, когда авария случится снова, соберите нам perfdata на этот момент, а пока мы вам ничем помочь не можем».

            Типа, запись, выполняющаяся всего 300 секунд — это всё правильно и хорошо.

              +2
              фигня эти ваши 300 секунд :)
              Sun Nov 2 05:18:23 MSK [fas3210:NwkThd_00:warning]: NFS response to client… for volume 0x744d82e6 was slow, op was v3 remove, 100 > 60 (in seconds)
              Sun Nov 2 23:01:33 MSK [fas3210:NwkThd_00:warning]: NFS response to client… for volume 0x744d82e6 was slow, op was v3 null, 4294967 > 60 (in seconds)
                +1
                Ого. Сумели что-то от саппорта добиться?
                  0
                  Если очень захотеть то таймаут можно получить на любом протоколе. Здесь статья об оптимизации, а не траблшутинге вашей конкретной ситуации.
                  –1
                  Вы эту историю торгуете на моей памяти уже два раза и это третий.
                  Статья никаким боком не касается вашего вопроса, кроме картинки NetApp FAS.

                  На сим прошу оффтоп закончить.
                    –1
                    Я её не «торгую», я её рассказываю, чтобы не дай бог кто-то не подумал, что netapp надежное решение. Очевидный баг, который компания признавать отказывается, типа так и должно быть.

                    Расскажите мне, как операция io может занять сотни секунд по причине берста нагрузки от клиента? Лично мне очевидно, что это заскоки в логике самого контроллера, то есть вся хвалёная wafl'ность просто не может и не должна использоваться для критичных по аптайму задач.

                    И коммент выше от madorc только подтверждает, что это распространенная (и, судя по всему, не пофикшенная проблема).

                    Лично моё возмущение сводится даже не к факту, что оно жидко какается, а что саппорт предлагает дождаться очередной аварии и собирать в это время perfdata, а потом пытаться продавать диски по дороже (ну что вы хотели от дисков по $1000 за штуку?).
                      –1
                      Вот именно об этом я и говорю хватит ее копи-пасть везде, где есть картинка нетапа. Прочтите название топика и вступление.

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

                      Еще раз: здесь топик не про траблшутинг, а я не техподдержка и даже не сотрудник нетапа, а тема про тюнинг езернет.
                        0
                        Вопрос был давно разрешен. Смотрите по ссылке.
                    +3
                    Здравствуйте.
                    У Вас на мой взгляд небольшая неточность:
                    То что произошло дальше — появилась «дуплексность», т.е. каждый узел мог одновременно и принимать и передавать фреймы по разным линкам: две пары RX и TX для узла и две для коммутатора.

                    Дуплексность появилась в 10BASE-T, IEEE 802.3i — для передачи данных используется 4 провода кабеля витой пары (две скрученные пары) категории-3 или категории-5. В категории 5 две пары запасные. Очень часто выручают) при разрыве передающей или принимающей пары.
                    Статья познавательная. Спасибо.
                      +2
                      Есть еще одна неточность:
                      Потом Ethernet шагнул дальше начал использовать витую пару дав задел на будущее, но глупые бриджи точно также объединяли все узлы сети в один домен коллизии и ситуация по сути не изменилась.

                      Бридж bridgeмост, устройство второго уровня модели OSI, которое осуществляет передачу, основываясь на MAC адресах.

                      Простым копированием пакетов с одного порта на все прочие занимались сетевые концентраторы — хабы.
                        +1
                        Спасибо, вы правы, подразумевал хаб.
                        0
                        Спасибо, добавил информацию.
                          0
                          Еще неточность про размеры mtu. Даже на 1 гбит. многие устройства до 9700 умеют, а у вас на 10Gb 9000 потолок.
                            0
                            А некоторое оборудование и 16К фреймы поддерживает
                              0
                              Здесь я специально говорил не совсем уж про все на свете коммутаторы. Но для тех, которые я привел в пример, проверял на сайте производителя. Идея была донести, что МТУ может быть разный, для разных устройств и его стоит подбирать в зависимости от того какой свич и узлы у вас есть чтобы значение совпадало на всем пути следования фрейма. И думаю мне эту мысль удалось донести.
                                0
                                Да конечно же 1ГБ может быть с jumbo frames. Но основная идея в том, что не иметь jumbo frames на 10гб это просто преступление.
                              0
                              --

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое