iSCSI 2.0 с FAS2xxx или путь масштабирования маленького ЦОДа

    Сохранение инвестиций востребовано любой компанией. Важно иметь такой концепт инфраструктуры ЦОД, который бы позволил в случае необходимости легкого масштабироваться, при этом максимально утилизировать существующее оборудование для новых потребностей бизнеса. Переход от iSCSI к iSCSI 2.0 может стать базой для такого концепта. iSCSI over DCB часто называют iSCSI 2.0 благодаря дополнительным расширениям DCB для Ethernet.


    В продолжение статьи "FC & Ethernet".

    DCB, состоит из
    • PFC (802.1Qbb) — Обеспечивает работу Ethernet без потерь фреймов (Lossless Ethernet)
    • ETS (802.1Qaz) — Назначает пропускную способность фреймам, позволяет низкоприоритетному трафику использовать пропускную способность если она не задейстована
    • CN (802.1Qau) — Ставит источник «на паузу»
    • DCBX — Определяет домен DCB

    Свичи поддерживающие DCB часто также поддерживают Shortest Path Bridging IEEE 802.1AQ и/или IETF TRILL позволяющие выбрать наиболее короткий путь для Ethernet трафика, что позитивно сказывается на работе iSCSI.

    iSCSI успел эволюционировать научившись работать с Thin Provisioning (SCSI SBC-3) и Space Reclamation (T10 UNMAP), у него есть возможности балансировки нагрузки и обеспечения отказоустойчивости путей (при помощи MPIO и/или MCS).
    Важно отметить что все хранилища NetApp FAS поддерживают протокол iSCSI на всех своих Ethernet дата-портах. Начиная с версии Data ONTAP 8.1.3 поддерживаются SCSI SBC-3 и UNMAP, начиная с версии DATA Ontap 8.2.1 системы хранения FAS поддерживают DCB.
    Таким образом iSCSI может стать идеальным кандидатом для роста маленького ЦОД, если обеспечит:
    • Высокую производительность (можно достичь при помощи не большего тюнинга, а также благодаря DCB).
    • Единый концепт подключения СХД в случае роста от «маленького» до «большого ЦОД», для сохранения инвестиций.
    • Относительно простой переход от дизайна «маленького ЦОД» direct-attached или Switched (с дешевыми свичами) подключений СХД к дизайну «большого ЦОД», для будущего роста.


    Для этого предлагаю рассмотреть преимущества и недостатки нескольких дизайнов соблюдая единый концепт — подключение СХД NetApp FAS по iSCSI. Эти дизайны должны быть относительно просты для преобразования маленького ЦОД в большой.

    Схематическое обозначение предлагаемых путей перехода между конфигурациями при росте ЦОД, а-ля квадрат Гартнера:


    iSCSI тюнинг


    По-скольку iSCSI живет поверх Ethernet, необходимо настроить Flow Control (не путать «обычный» FlowControl с PFC IEEE 802.1Qbb для DCB Losless Ethernet) и настроить Jumbo Frames на сетевых адаптерах хостов, на СХД и на свичах (если они есть). Использование MPIO/MCS внутри одного линка может увеличить его суммарную пропускную способность по сравнению с использованием одного соединения в линке. Рекомендуется выделить отдельный VLAN для iSCSI трафика если свич используется для смешанного типа трафика.

    Directly-Attached iSCSI


    Дизайн такого «маленького ЦОД» состоит из одного-двух серверов напрямую подключённых в СХД каждый минимум двумя линками для отказоустойчивости: один к одному контроллеру СХД, другой к другому. На этом этапе вполне логично использовать бесплатный Software iSCSI Initiator. В случае увеличения хоcтов необходимо или добавить порты на хранилище или установить свичи. В зависимости от модели хранилища может быть разное количество Ethernet портов. Важно отметить что все Ethernet порты на хранилищах NetApp FAS (нет «выделенных» iSCSI портов) могут быть использованы для таких типов трафика: iSCSI, NFS, CIFS (SMB), в том числе и одновременно.
    • Положительной стороной является относительная дешевизна (не нужны специализированные адаптеры для хостов, не нужны свичи) и простота.
    • Отрицательной стороной такого решения будет низкая масштабируемость и дополнительная нагрузка на CPU хоста выполняющего функцию Software iSCSI Initiator.


    Attribute Value
    Fully redundant Yes
    Type of network None, direct-attached
    Different host operating systems Yes, with multiple-host configurations
    Multipathing required Yes
    Type of Storage configuration HA pair


    Switched iSCSI


    В такой схеме необходимо иметь как минимум два линка от каждого узла, каждый линк подключённый через разные коммутаторы. Это обеспечит полную отказоустойчивость при выходе контроллера, свича или пути. На этом этапе всё еще можно использовать Software iSCSI Initiator или комбинацию с выделенным iSCSI HBA (который офлоадил бы нагрузку с CPU хоста).
    • Обновление с Direct-Attached конфигурации относительно простое и может быть выполнено без отключения сервиса, возможно понадобится добавить пару дополнительных путей после подключения свичей. В случае необходимости установки iSCSI HBA адаптера, остановка хоста неизбежна.
    • К положительной стороне такого дизайна можно отнести относительно высокую масштабируемость, простоту настройки и дешевизну сети.
    • К отрицательной стороне такого решения можно отнести потерю фреймов в сети ведущую к увеличению отклика между хранилищем и хостом. Для небольших конфигураций обеспечит более чем приемлемый уровень отклика.

    image
    Attribute Value
    Fully redundant Yes
    Type of network Multi-network
    Different host operating systems Yes, with multiple-host configurations
    Multipathing required Yes
    Type of Storage configuration HA pair


    iSCSI 2.0


    Так же как и Switched iSCSI, в случае iSCSI 2.0 используются свичи, но они должны поддерживать DCB. В этом дизайне также понадобятся сетевые адаптеры поддерживающие DCB как на хосте так и на хранилище. Таким образом DCB должен поддерживаться на всем пути следования iSCSI трафика. DCB известен также как Lossless Ethernet, он обеспечивает гарантированную доставку фреймов повышая надежность, производительность и скорость отклика до уровня FC. Важно отметить, что DCB поддерживают все конвергентные Ethernet порты на хранилищах NetApp FAS (нет «выделенных» iSCSI или FCoE портов) и могут быть использованы для всех типов трафика: iSCSI (2.0), FCoE, NFS, CIFS (SMB), в том числе и одновременно. На хосте поддерживаются CNA (HBA) адаптеры QLogic 8300 для работы с DCB, этот адаптер позволяет оффлоадить нагрузку с CPU хоста обеспечивая низкую скорость отклика хранилища. Некоторые дополнительные фичи свичей могут улучшить и без того низкий уровень отклика для iSCSI, к примеру CLEAR-Flow.
    • Таким образом для перехода от Switched iSCSI к iSCSI 2.0 необходимо заменить сетевые карты и свичи на DCB совместимые, полостью оставляя топологию сети и схему мультипасинга, как она была. DCB настраивается на сетевых картах и свичах. Оставшиеся после замены старые «обычные» свичи можно задействовать для подключения клиентов к серверам. Обновление с Switched iSCSI конфигурации без приостановки в обслуживании возможно при условии что iSCSI HBA адаптер уже установлен в хост. В случае необходимости установки iSCSI HBA адаптера, остановка хоста неизбежна.




    К преимуществам iSCSI over DCB можно отнести:
    • Относительная простота настройки коммутаторов
    • Низкий отклик от хранилища до приложения
    • Возможность использования QoS в средах со смешанным трафиком
    • Предотвращает потерю фреймов и увеличивает жизнеспособность фреймов Ethernet
    • Увеличенная производительность IP протоколов включая iSCSI.


    К недостатки iSCSI over DCB:
    • Архитектура предусматривает не большое число хопов от хоста к хранилищу, в идеале хоп должен быть один.
    • Необходимость расчёта уровня переподписки и соблюдения коэффициента Fan-In в случае увеличения чила хопов.


    Attribute Value
    Fully redundant Yes
    Type of network DCB, Dual fabric
    Different host operating systems Yes, with multiple-host configurations
    Multipathing required Yes
    Type of Storage configuration HA pair


    • Запасной вариант: Все конвергентные порты NetApp FAS лекго могут быть модифицированы простой заменой SFP+ модулей, вместо Ethernet свичей с DCB для iSCSI всегда можно купить FC свичи или задействовать те же Ethernet свичи с DCB для подключения по FCoE, а так как NetApp FAS поддерживает доступ к одному и тому же луну по всем этим протоколам, переключение между протоколами FC/FCoE/iSCSI происходит без потери данных или конвертаций. К отрицательной стороне FC и FCoE можно отнести относительно высокую сложность в настройке коммутаторов. Выбирая между FC и FCoE обратите внимание на статью "FCoE: Будущее Fibre Channel" и статью "Консолидация LAN и SAN сетей ЦОД на базе протоколов DCB и FCoE"


    Масштабирование FAS


    Есть несколько путей роста систем NetApp FAS:
    1. Добавить полки с дисками (без останова)
    2. Объединить систему в кластер с такой же или старшей маделью (без останова)
    3. Конвертировать контроллер FAS255x в полку, докупить новые контроллеры, переключить конвертированную и все остальные полки на новые контроллеры (простой не избежен)
    4. Объединить в кластер, мигрировать данные в онлайне, вывести старую систему из кластера, конвертировать FAS255x в полку и переключить старые полки в новую систему (без останова)


    Выводы


    Таким образом протокол iSCSI с хранилищем NetApp FAS может быть базой для начала роста от «маленького ЦОД» до «большого», поэтапно и просто обновляя дизайн сети, соблюдая единый концепт адресации и мультипасинга. При обновлении максимально утилизируется уже приобретённое оборудование. Каждый шаг обновления повышает масштабируемость инфраструктуры ЦОД, её скорость и уменьшает отклик для приложений, при этом выполняя затраты по мере необходимости. Благодаря универсальности СХД FAS, поддержке передовых тенденций развития ЦОД и возможности взаимно заменять протоколы (или использовать их все одновременно в том числе и по тем же портам), легкой масштабируемостью, она является хорошим инвестиционным вложением как для малых так и «больших ЦОД».

    Лучшие практики


    Подробнее о рекомендациях топологии сети и зонирования для NetApp в картинках.
    Очень важно соблюдать лучшие практики при конфигурировании инфраструктуры и проверять матрицу совместимости для достижения максимальной производительности и отказоустойчивости:
    TR-3441 Windows Multipathing Options with Data ONTAP: Fibre Channel and iSCSI
    WP-7071: «How Do I Get to Ethernet from Here?»
    TR-3519: «The Road to 10-Gigabit Ethernet»
    WP-7046: «Ethernet Storage»
    TR-3441: «iSCSI Multipathing Possibilities on Windows with Data ONTAP»
    TR-3163: «Data Protection and Recovery for Network-Attached Storage over IP/Ethernet Networks»
    WP-7052: «Converged Enhanced Ethernet—Good for iSCSI SANs»
    TR-3519: «The Road to 10-Gigabit Ethernet»
    iSCSI 10Gig Performance Tuning With Windows Server
    iSCSI Configuration and Provisioning for Windows
    TR-3802 Ethernet Storage Best Practices
    TR-4182 Ethernet Storage Design Considerations and Best Practices
    Best Practices for Network Configuration with NetApp Storage Systems
    NetApp Verifying that DCB is configured correctly
    Доступны для прохождения курсы «NetApp SAN Design» и «SAN Fundamentals on Data ONTAP» в академии NetApp.

    Источники:
    sniaesfblog.org/?p=210&cpage=1#comment-82839
    blogs.cisco.com/datacenter/the-napkin-dialogues-lossless-iscsi
    www.storage-switzerland.com/Articles/Entries/2012/1/17_iSCSI_2.0_-_Using_Data_Center_Bridging_To_Enhance_iSCSI.html
    www.snia.org/sites/default/education/tutorials/2010/spring/networking/GaryGumanow-JasonBlosil_iSCSI_Lossless_Ethernet_DCB.pdf
    www.slideshare.net/extreme-muk/i-scsi-extremeintelnetappclearflow

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

    Ну. И что?
    Реклама
    Комментарии 17
    • +1
      Очень компактно и познавательно!
      А есть ли какая-то статистика, насколько именно Soft iSCSI Initiator нагружает CPU, может есть примеры с конкретной нагрузкой и железом?
      • 0
        Существует по-сути три типа подключения по iSCSI:
        • Чистый Software Initiator
        • Software Initiator c TOE
        • iSCSI HBA



        Следующие возможности аппаратного ускорения работы сетевого адаптера (TOE NIC) могут снизить нагрузку на CPU хоста:
        • Receive Side Scaling (RSS)
        • TCP Chimney Offload
        • Jumbo Frames
        • Large Send Offload

        Обратите внимание, что не все сетевые адаптеры с TOE поддерживают все перечисленные функции.

        Аппаратные HBA адаптеры для iSCSI, к вышеперечисленному, берут обработку ещё и четвертого уровмя модели OSI, они собственно аппаратно обрабатывают сам протокол iSCSI.

        В эру многопроцессорности и высоких скоростей CPU появляется большое множество вариантов сравнения. Так к примеру некоторые HBA адаптеры построены на базе обычного x86 CPU. Настройки, наличие или отсутствие каких-то функций, к примеру DCB или включение функции Jumbo Frames в Software и iSCSI HBA могут существенно влиять на результыты нагрузки CPU.

        Другими словами проще взять и проверить нагрузку самому, так как в вашем случае с вашим оборудованием, разница между какими-то статистическими данными может оказаться существенная. Для этого вы можете восспользоваться утилитами по генерации нагрузки, к примеру IOMeter.

        К примеру, на сервере с двумя quad-core Intel® Xeon® E5405 процессорами с частотой 2.0 GHz, 16 GB памяти и установленным
        • 10GB адаптером (c TOE), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 15%. В случае увеличения размера блока (до 64 KB), утилизация CPU может достигать 26%.
        • 10GB адаптером (c iSCSI HBA), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
        • адаптером 1 GbE (с TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 2%.
        • адаптером 1 GbE (с выключенным TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 3%.
        • адаптером 1 GbE (с iSCSI HBA), можно достичь 110 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
      • +1
        Почему именно iSCSI?
        • +1
          Потому что он хорош как для маленького ЦОД так и для большого. Для маленького не нужно покупать HBA адаптеры или специальные свичи. На начальном этапе можно задействовать обычные свичи. При росте с маленького до большого не меняется вся концепция, собственно об этом вся статья. Ну и производительность у iSCSI с 10GbE подключением ничем не хуже FC8, по крайней мере так у NetApp (у других производителей эта ситуация может быть другая). Благодаоя тому, что iSCSI не уступает по производительности и при этом живет поверх Ethernet, есть возможность клнсолидировать блочный трафик с другим трафиком на одном и том же сетевом оборудовании, таким образом есть возможность допрлнительно сэкономить. А приоритизация трафика позволит смешивать высокоприоритетный трафик с остальным без компромиса. И конечно же с NetApp FAS вы всегда вольны переключаться между iSCSI/FC/FCoE.

          Универсального рецепта, конечно же нет. Каждый взвешивают интересующие именно его, «за» и «против».
          • 0
            Какие альтернативы для малых ЦОД? iSCSI лучше, чем ...? Как-то вы замалчиваете эту тему.
            • 0
              Альтернатива блочному iSCSI это FC и FCoE.
              Есть еще варианты файловых протоколов NFS и CIFS (SMB), но так как у этих протоколов нет встроенного мультипасинга и балансировки нагрузки, этот недостаток им нужно компенсировать чем-то. Такой компенсацией являются LACP с EtherChannel или лучше LACP с Multi Chassis EtherChannel. Соответственно первый вариант с файловыми протоколами и прямым подключением реализовать не удастся, для этого понадобится не любой, а свич с вышеперечисленным функционалом, на котором нужно будет еще настроить этот функционал.
              • 0
                А в плане возможностей балансировки нагрузки для малых ЦОД, к примеру с двумя серверами и 4 сетевыми линками от каждого узла, балансировка LACP будет иметь существенные недостатки, по сравнению с блочным протоколами, для приведенного примера из-за внутреннего устройства балансировки трафика.
                Для того чтобы обойти эти ограничения, для малых инфраструктур, необходимо предпринимать ряд дополнительных действий.
                habrahabr.ru/post/215351
                • 0
                  А не будет ли для малых ЦОД внешний SAS-сторидж лучшим решением для двух серверов? Как-то FC в малых ЦОД выглядят не вполне бюджетно.
                  • 0
                    О SAS могу сказать из того, что я видел — SAS используют для подключения полок к СХД. Не смотря на то, что существуют в природе SAS свичи, во всех ЦОДах которые я видел, от миниатюрных до очень-больших, нигде не было SAS свичей. Даже JBOD полки для серверов почему то мне не попадались на глаза. По-видимому владельцы ЦОДов не рассматривают SAS свичи как замену блочным FC/FCoE/iSCSI, а также по каким-то причинам не спешат адаптировать такие дизайны в своих ЦОДах. В то же время iSCSI (работающий поверх Ethernet) продолжает отъедать долю у других блочных протоколов и встречается в 1/3 всех ЦОД которые я видел.

                    Мне сложно сравнивать SAS протокол с FC/FCoE/iSCSI, так как я не много знаю о его преимуществах. Следя за тенденциями и новыми развивающимися технологиями ЦОД, нигде для себя не замечал каких-то специальных, особых возможностей SAS, для того чтобы он занял место одного из выше перечисленных протоколов. Похоже он занял свою нишу и останется там.

                    Среди протоколов которые набирают популярность в ЦОД для подключения разнообразных хранилищ стоит отметить Ethernet.

                    Собственно об этом и статья, как сделать так, чтобы и бюджетно, и в будущем «лишнего» не покупать, и при этом всём иметь возможность вырасти, максимально утилизируя имеющееся оборудование.
                    • 0
                      JBOD не проблема. Как и свичи (см. коммент ниже).
                      • 0
                        Я говорю, что почему-то широко это не исспользеутся, везде где я бывал. А бывал я во многих ЦОДах.
                        Может по-этому?
                    • 0
                      Что-же касается одного-двух серверов, то на мой взгляд лучше выбрать, сразу такую технологию, которая позволит масштабироваться вашему ЦОДу в будущем. И если SAS по-вашему мнению обеспечит такую возможность, почему бы и нет.

                      Но как я сказал ранее, смотрю со скептицизмом на SAS свичи потому, что их нигде в продакшине не видел.
                      • 0
                        По поводу SAS-свичей пригодится материал на Хабре. Там же есть полезный коммент, поясняющий "популярность Ethernet в ЦОД для подключения разнообразных хранилищ". Вот он: iSCSI для проброса в другой город, SAS из области DAS.
                        • 0
                          Относительно приведенной ссылки, должен отметить, то латентность, как правило ухудшается не из-за сети, а из-за недостатка дисков. Собственно автор сам отметил что все было хорошо пока виртуальная инфраструктура не выросла. Так что сравнение FC и SAS в приведенном примере не корректно. Естественно на FC/FCoE/iSCSI латентность можно получить на много ниже, к примеру 1 мс на SSD дисках. Это простой пример показывающий что дело в основном в дисках, а не сети.
                          • 0
                            Кстати очень важно отметить важный феномен.

                            Следом за ростом компании неизбежно следует рост ЦОД. И админы такого ЦОДа должны немного опережать его развитие. А получается что они немного запаздывают:
                            Вместо того, чтобы админы думали об масштабируемости, отказоустойчивости, управляемости, репликации, удобстве резервного копирования и восстановления, они, «во главу» всего ставят «цену вопроса». И лишь спустя время, жизнь учит, расставит приоритеты и утрясёт всё так, что «цена вопроса» для них смещается с первого места. Иногда смещение происходит вместе с админом с рабочего места. И тогда они понимают, что «не в производительности счастье».

                            Симметрично этому феномену существует ещё один, который наблюдается в руководстве компании, заключается он в том, что финансы выделять не хоят они, а ответственность за работоспособность ЦОДа спрашивают почему-то с админов. По именно руководство бизнеса провоцирует первый феномен. и только после «Шеф всё пропало», финансы на «правильные» решения чудесным образом находятся.

                            Мой совет заключается в том, чтобы не допустить ситуации «финансы НЕ выделили мы, а ответственные за неработоспособность вы».
              • 0
                Картинка с сравнением Roadmaps Ethernet и FC очень «маркетинговая» в начале статьи. Официальные лица от FC пишут о другом тут: fibrechannel.org/fibre-channel-roadmaps.html
                Например: 2016 год — это скорость интерфейсов 128G, а к 2019 году — 256Gb. Причем техническая спецификация на 128Gb была готова уже в 2014 году.

                • 0
                  Картинка не моя, а SNIA.org. Я добавил информацию по доступности функционала у NetApp, даты проверены.

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

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