Будущее Ethernet & FC

    Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
    Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.


    * по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.


    Проблемы Ethernet

    С выходом 1Gb, Ethernet теряет многие свои детские болезни, связанные с потерей фреймов. В 2002 и 2004 приняты самые популярные стандарты Ethernet 10 Gb/sec. Протокол улучшает пропускную способность с применением нового алгоритма кодирования 64b/66b (пропускная способность 10*64/64 Gb). В 2007 продано 1 миллион 10Gb портов.
    Ethernet 40 Gb/sec и Ethernet 100 Gb/sec используют тот же алгоритм кодирования 64b/66b, оба стандартизированы в 2010. Некоторые производители предоставили реализацию наброска будущего стандарта 40/100 Gb ещё в 2008.

    Data Center Bridging

    Стандарты DCB (иногда именуемых Lossless Ethernet) разрабатывались двумя независимыми группами IEEE 802.1 и IETF в период с 2008 по 2011. Два разных термина применяются в отношении продуктов доступных на рынке, базирующихся на этих стандартах: DCE и CEE:
    Подробнее про DCB и CEE рекомендую почитать и позадавать вопросы, в соответствующем посте компании Cisco: "Консолидация LAN и SAN сетей ЦОД на базе протоколов DCB и FCoE".

    Converged Enhanced Ethernet

    Здесь нужно отдельно отметить, что Ethernet под передачу FC был доработан (2008-2011), при этом TRILL здесь не применим. Для реализации FCoE, были разработаны механизмы, которые имитируют buffer-to-buffer кредиты в FC, такие как: Priority Flow Control 802.1Qbb (Draft 2008, Standard 2011), Bandwidth Management 802.1Qaz (Draft 2008, Standard 2011) и Congestion Management (резерв полосы, отсутствие дропов) 802.1Qau (Draft 2006, Standard 2010). Впервые FCoE появился в коммутаторах Cisco.

    Перспективы скоростей для FC

    FC8 на момент 2014 самый популярный среди FC и FCoE.
    FC16, доступен с 2011, начал приобретать широкое распространение в 2014.
    FC32, проект выпуска запланирован на 2016 (прогноз).
    FC128, проект выпуска запланирован на 2016 (прогноз).

    «Чисто-блочные» СХД

    Все «чисто-блочные СХД» обзаводятся файловыми шлюзами. Знаменитая фраза «Real deal FC» (2008) бывшего руководителя одного крупного производителя СХД в то время, как бы подчёркивала, что в сетях ЦОД FC это лучший выбор. Тем не менее, IBM разрабатывает свои SONAS (2010), Hitachi покупает BlueArc (2011) для предоставления файлового доступа, EMC и HP применяют сервера с Windows для предоставления доступа по протоколу SMB и Linux для NFS. Все вышеупомянутые также теперь предоставляют возможность использования iSCSI.
    Это разнообразие вариантов по сути использует Ethernet.

    Файловые протоколы поверх Ethernet

    В 1997 Oracle с NetApp выпускают решение для БД расположенных на NAS хранилище. Файловые протоколы, использующие Ethernet, находят своё применение в высоконагруженных и критически важных приложениях. Эволюция файловых протоколов приводит к использованию Ethernet в приложениях, которые ранее использовали только блочный FC. В 2004 Oracle запускает Oracle On-Demand Austin (USA) Data Center использующий системым хранения NetApp FAS.

    Microsoft разработала новую версию протокола SMB 3.0 (2012), теперь критически важные приложения как виртуализация, БД и др. могут жить в сетевой папке. Многие проихводители СХД сразу же объявляют о будущей поддержке этого протокола. В 2013 NetApp выпускает совмесно с Microsoft решение Hyper-V on SMB 3.0 и MS SQL on SMB 3.0.
    В БД Oracle 11g (2007) добавлена новая функция dNFS, для расположения файлов БД в сетевой папке NFS.
    NFS v4.0 (2003) — в протоколе меняется парадигма пространства имён. Теперь сервера вместо экспорта множественных файловых систем экспортируют одну псевдо-файловую систему собранную из множества реальных файловых систем и что важно, предоставляет новые возможности High-Availability для сетей ЦОД, такие как: прозрачная репликация и перемещение данных, перенаправляя клиента с одного сервера на другой; таким образом позволяя поддерживать глобальное пространство имён, при этом данные находятся и обслуживаются одним выделенным сервером. Это очень тесно взаимосвязано с построением кластерных систем и сильно упрощает их реализацию.
    NFS v4.1, pNFS — (2010) параллельный NFS позволяет клиентам получать доступ к файлам через «ближайшие» линки без пере-монтирования. В 2012 компании NetApp вместе с RedHat объявляют о сотрудничестве в поддержке pNFS для Clustered Ontap и RHEL 6.2.
    К преимуществам протоколов работающих поверх IP можно также отнести их возможность маршрутизации, которая дробит широковещательные домены в таких сетях. Для протоколов SMB 3.0 и NFS 4.0 архитектурно была заложена оптимизация для работы в WAN.

    Конвергентные устройства


    Выпуск конвергентных сетевых коммутаторов, таких как Cisco серии Nexus в 2009 приводит к тому, что их применение объединяет традиционную FC SAN сеть с сетью Ethernet, это позволяет более гибко IT подразделениям отвечать на изменяющиеся потребности бизнеса. Компания NetApp впервые запускает поддержку конвергентных сетей и нескольких протоколов по одному проводу (2010). Изначально передача FCoE поддерживалась только по оптике и по Twinax кабелям.
    Появляются onboard 10Gb адаптеры в 2012 с «медными» портами.
    Следом в 2013 появляются onboard CNA2 адаптеры второго поколения с разъемами SFP+, они могут использовать как для Ethernet, так и FC8/FC16.

    Выпуск адаптеров CNA позволяет использовать FCoE и Ethernet в сетях ЦОД, предоставляя возможность получать лучшее от обоих, позволяя применять наиболее подходящие протоколы для решения различных задач.
    Начало широкого применения адаптеров CNA2 (2014) в СХД NetApp, позволяющие одновременно использовать FCoE и Ethernet или «чистый» FC8/FC16. Конвергентные порты вытеснили практически все дата порты на новых системах хранения NetApp FAS8000, оставив «в чистом виде» только 1GbE. Вместе с CNA адаптерами появляются конвергентные SFP+ трансиверы, которые могут переключаться между режимами роботы FC/Ethernet, к примеру в СХД NetApp E-Series.

    Объектные хранилища поверх Ethernet

    Объектные хранилища всё больше набирают популярности и в 2013 Seagate выпускает свои объектные жесткие диски Kinetic с Ethernet интерфейсом. А в 2014 компания HGST выпускает свои жесткие диски Open Ethernet. NetApp в 2010 году покупает StorageGRID (ранее прродукт компании Bycast Inc. ), первая инсталяция объектного хранилища 2001г.

    Масштабирование и кластеризация

    Один из лидеров решений среди NAS кластеризации была компания Spinnaker Networks, начавшая как Start Up и поглощённая компанией NetApp в 2003, её разработки легли в основу современной ОС Clustered Ontap для СХД NetApp FAS.
    Наибольшие кластера СХД предоставляющие доступ по блочному протоколу FC достигают 8 нод для NetApp FAS6200/8000, в то время как у конкурентов это обычно не более 4х нод. Для файловых протоколов число нод может быть в разы больше — 24 ноды для NetApp (2013) FAS6200/8000 (SMB, NFS). А для объектных хранилищ число нод теоретически не ограничено. В современном мире, где сравнительно не дорогие кластеризованные ноды с возможностью масштабирования по мере необходимости, могут стать более предпочтительным выбором в отличие от «подхода Mainframe», где используется один дорогой суперкомпьютер.

    Максимальный размер LUN'а часто может оставлять желать лучшего: достигать 16TB и иметь ограничения по количеству LUN'ов, как на стороне хоста так и со стороны СХД. В кластерезированных СХД этот порог никуда не пропал и для получения большего объема часто применяют решения типа «костыль», объединяя несколько LUN'ов на софтверном уровне на хосте. Файловые шары могут занимать Патабайты и достаточно легко масштабироваться, получая одну огромную логическую сетевую папку в размере нескольких Петабайт, в СХД NetApp FAS это достигается при помощи технологии Infinite Volume с доступом по протоколам SMB и NFS.

    ThinProvitioning & Snapsots

    Впервые технология snapshot была разработана и внедрена компанией NetApp в 1993, а технология Thin provisioning впервые была представлена в 2001 и впервые представлена в СХД 3Par в 2003 и следом у NetApp FAS в 2004. Несмотря на то, что непосредственного отношения эти две технологии не имеют ни к Ethernet с его SMB, NFS ни к FC, всё же в плане удобства использования Thin Provisioning и Snapshots «на стыке» с «файловыми» и «блочными» протоколами очень отличаются друг от друга.
    Так к примеру, если у вас используется «тонкий» LUN и при этом место на СХД «на самом деле» закончилось, все приличные СХД переведут такой LUN в режим офлайн, чтобы приложение не пыталось туда писать и не испортило данные на нём. Аналогичная ситуация произойдёт когда снепшоты «съедят» всё пространство актуальной файловой системы и не оставят место для самих данных в тонком LUN'е. Также неприятной особенностью «тонких» LUN'ов всегда было то, что он всегда «растёт», даже если данные удаляются на уровне файловой системы живущей «поверх» LUN'а, хранилище этого LUN'а ничего об этом не знает.
    В то же время для файловых шар тонкое планирование предоставляется, что говориться «by design» и уж точно окончание пространства не переведёт сетевую папку в офлайн.

    Заимствование функционала

    Так в ОС Windows 2012, RedHat Enterprise Linux 6.2 (2011) и VMWare 5.0 (2011) могут запускать функцию Logical Block Provisioning как определено в стандарте SCSI SBC-3 (что часто называют SCSI thin provisioning), который «объясняет» ОС, что LUN на самом деле «тонкий» и место на нём «на самом деле закончилось», запрещая проводить операции записи. Таким образом, ОС должна перестать писать в такой LUN, а он сам не будет переведён в офлайн и останется доступен только на чтение (другой вопрос как на это отреагирует приложение). Этот функционал также предоставляет возможность использования Space Reclamation, который позволяет LUN'ам уменьшаться, после удаления актуальных данных на нём. Таким образом, LUN'ы теперь более адекватно работают в режиме тонкого планирования. Так спустя 8 лет «Thin Provisioning Awareness» докатился от СХД (2003) до хоста (2011).
    Что касается кластеризированных решений для хостов, то в отличие от сетевых папок, с одним LUN'ом долгое время мог работать (читать и писать) только один хост. Все остальные хосты могли только лишь читать этот LUN. Но и здесь пришло решение спустя время, Block или Region Level Locking Mechanism — можно разбивать LUN на логические участки и предоставляя нескольким хостам возможность писать только в «свои» участки. В то время как у сетевых папок эта функция заложена в дизайн протокола и присутствовала с самого возникновения.
    С другой стороны у сетевых папок не было никогда функциональности на подобии Multipathing, которая позволяла бы клиенту запрашивающему файл, обращаться к нему по нескольким путям или по кратчайшему пути. Этого всегда не хватало файловым протоколам, так появился pNFS, частично этот недостаток закрывался LACP, позволяя балансировать трафик между несколькими коммутаторами при помощи технологии vPC.

    Заключение

    По-видимому, функционал всё дальше будет заимствоваться, сближая протоколы. Конвергенция видится неизбежным будущим в виду перечисленных выше событий. Это заставит два протокола ещё более жестко бороться за сферы применения в сетях ЦОД. Реализация кластерных СХД с доступом по блочному FC протоколу имеет более сложную архитектуру, технические ограничения по размеру LUN'а и их количеству, что не играют в пользу будущего развития этого протокола в современном мире постоянно растущих данных и парадигме кластеризации, требуя доразвития в этом направлении. Также Ethernet очень опережает по скорости FC, что может сказаться на будущем последнего, в связи с чем есть предположение что FC сместиться внутрь Ethernet и останется жить там, в виде FCoE. Ведь по сути разница в 8мь лет: 100Gb 2008 и 128Gb в 2016. Выбирая между FC и FCoE обратите внимание на эту статью.

    Хочу отметить, что здесь не рассматривались не распространённые варианты типа IP поверх FC и прочих всевозможных сочетаний протоколов, а только наиболее часто использующиеся комбинаций протоколов в инфраструктурных дизайнах ЦОД, которые и формируют тренды будущего.

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

    Ну. И что?
    Реклама
    Комментарии 19
    • +1
      Мне кажется, или сетевики разговаривают на своем, малопонятном для окружающих, языке?
      (Картинка из футурамы)

      Несмотря на то, что всё в целом понятно из статьи, не покидает ощущение что прочитал странцицу из учебника по квантовой механике.
      • 0
        Предложите в ЛС как переделать :)
      • 0
        Извините, а объектное хранение вообще на чем-то кроме Ethernet делают? С учётом модели «из всякого хлама методом повышения доступности за счёт избыточности», а так же TCP сверху — чему там быть, кроме самого дешевого за мегабит? Был бы fc дешевле, юзали бы его.
        • 0
          Объектное хранилище может быть реализовано на нескольких уровнях, к примеру на уровне интерфейса и на уровне устройства и протокола.
          Как наглядный пример, когда мы говорим про уровень интерфейса (жесткого диска), то мы можем взаимодействовать как с объектным хранилищем, но внутри все команды (могут)выполняются «стандартными» SCSI командами.
          Если мы говорим про «уровень устройства и протокола», то был реализован набор специализированных SCSI команд для «объектного» управления. Другими словами такие команды могут работать как поверх FC и Ethernet не единственная подходящая для того среда.

          Но в статье как раз речь не про всякие возможные варианты комбинаций протоколов,
          а только наиболее часто использующиеся комбинаций протоколов в инфраструктурных дизайнах ЦОД, которые и формируют тренды будущего.
          • –1
            Давайте не играть словами. Есть свифт, который поставил вендоров Очень Дорогих Железок в Очень Неудобное Положение. Есть конкуренты свифта (тот же ceph) — но с ними ситуация не легче. В результате приличный кусок рынка был отъеден начисто. А сейчас ceph начинает есть оставшееся. Остаётся только окучивать консервативный энтерпрайз — но и тот когда-нибудь закончится.

            Вот сигейты поняли — и радостно бросились в объятия с клиентами без прослойки вендоров посредине.

            Но модель простая — чем дешевле, тем лучше. «Могут работать» при условии, что так дешевле. Свифту вообще насрать на технологию — есть возможность tcp сделать — будут тапки. Нет tcp — нет тапок.
            • 0
              Аж самому интересно как это мы с «FC и Ethernet» > «Object storage» > «Свифт и Ceph» > и далее к стоимости «Очень Дорогих Железок» перепрыгнули :) Это я вам легко намекаю на то что офтопик в «кубе» уже получается.

              Самого интересует SD*, мне кажется это очень положительное явление. Конечно же вопрос не стоит о том, будет ли иметь место в будущем SD*. Это неизбежное будущее, вопрос только во времени, когда это будущее будет «доступно массам» (в широком понимании этого выражения).
          • 0
            Возможно потому объектное хранение и предпочитает «комодити» оборудование и Ethernet потому, что так дешевле.
            • –2
              Именно, именно. Ради этого оно и создавалось. Чтобы не надо было закупать «вендоровские диски» по $1k за штучку (и коммутаторы по $50-200k).
              • 0
                Почему у вендоров дорогие запчасти это отдельная тема разговора и по моему мнению эта цена вполне оправдана. Нравятся вам или мне вендоры с их дисками и другими дорогими железяками, это не важно.

                Важно, что с исторической точки зрения эти вендоры были двигателями прогесса и многих современных технологий, теперь уже доступных в виде опенсорса.
          • +1
            Таймлайн интересный. Правда ощущение, что с 1992 по 2001 инновайций вообще не было :)
            • 0
              Если есть что-то стоящее, что упущено — пишите, добавлю :)
              • 0
                Если есть что-то стоящее, что упущено — пишите, добавлю :)
                • 0
                  Да, кстати, спасибо за ссылку по таймлайну нетапа!
                • +1
                  Спасибо за статью, очень хорошо написано, по SAN вобще как-то мало материалов, потому в избранное однозначно
                  • 0
                    Спасибо за спасибо. Три дня убил на подготовку материала, написание и оформление :)
                    Вот бы то количество просмотров и добавления в избранное в карму трансформировать.

                    А то стараться — старался, а кармы как небыло голосовать так и нет…
                    • +1
                      Оно того стоило! Мы сейчас больше с equallogic работаем но там чисто iscsi из коробки, а для файловых протоколов решение отдельно которое подключаться по iscsi к группе массивов, собираемся пощупать в ближайшие месяца
                  • 0
                    То есть езернет всех скоро победит?
                    Кроме FC вроде ещё был какой то протокол же?
                    А вспомнил infiniband
                    как то вы его сильно пропустили
                    • 0
                      Холивар устраивать здесь не хотелось бы, есть исторические события я их описал.

                      Что касается второго вопроса, то как правило ни Ethernet ни FC с Infiniband не могут потягаться по скорости отклика. Infiniband я не брал, та как совсем не та «весовая категория», да и распространение пока что оставляет желать лучшего. Ну и скажу прямо — с этой технологией я слабо знаком. Хотя, конечно же она имеет непосредственное отножение к ЦОД.
                      • +1
                        Очень мало ЦОД'ов, где широко используется IB. И основные причины вполне очевидны:

                        • Обслуживание 40G Ethernet в разы дешевле обслуживания Infiniband FDR, как с точки зрения стоимости порта, так и с точки зрения стоимости инженера, а включение Jumbo Frames для Ethernet нивелирует мнимое преимущество 4k фремов IB;
                        • Дискаунтеров среди вендоров оборудования для IB switched fabric нет, да и вендоров уже можно по пальцам одной руки пересчитать. Чего не сказать про выбор для Ethernet, особенно когда наши китайские друзья уже научились делать неплохое оборудование в своей ценовой категории;
                        • Ограничения по длине оптической трассы, так легко развенчанные для Ethernet мультиплексированием, для IB пока что туманны и требуют инкапсуляции во что-то более съедобное по пути;
                        • Существует не так много бизнесов, где требуется такой быстрый отклик.

                        Наверно, имеет смысл считать, что там, где сейчас должен был бы быть IB, крепко держится SAS.

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

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