Ethernet & FC05.06.2014 10:33

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

Таймлайн2

Проблемы 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.Стоит отдельно отметить, что стандарт 802.3 всё же допускает дропы в любом количестве по любым причинам на любых скоростях. В 2011 с появлением протокола TRILL для свитчей ЦОД «устраняют» последние детские болезни «чистого» Ethernet.Здесь нужно отдельно отметить, что Ethernet под передачу FC был доработан (2008–2011). Для реализации FCoE, был разработан механизмы, которые эмитируют buffer-to-buffer кредиты в FC (Lossless Ethernet) и не официально именуются «Data Center Bridging», такие как: 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.FC128, проект выпуска запланирован на 2016 (прогноз).«Чисто-блочные» СХД Все «чисто-блочные СХД» обзаводятся файловыми шлюзами. Знаменитая фраза «Real deal FC» (2008) бывшего руководителя одного крупного производителя СХД в то время, как бы подчёркивала, что в сетях ЦОД FC это лучший выбор. Тем не менее, IBM разрабатывает свои SONAS (2010), Hitachi покупает BlueArc (2011) для предоставления файлового доступа, EMC и HP применяют сервера с Windows для предоставления доступа по протоколу CIFS и Linux для NFS. Все вышеупомянутые также теперь предоставляют возможность использования iSCSI.Это разнообразие вариантов по сути использует Ethernet.Файловые протоколы поверх Ethernet Файловые протоколы, использующие Ethernet, находят своё применение в высоконагруженных и критически важных приложениях. Эволюция файловых протоколов приводит к использованию Ethernet в приложениях, которые ранее использовали только блочный FC: Microsoft разработала новую версию протокола CIFS 3.0 (2012), теперь критически важные приложения как виртуализация, MS SQL и др. могут жить в сетевой папке.В БД Oracle 11g добавлена новая функция dNFS, для расположения файлов БД в сетевой папке NFS.NFS v4.0 (2003) — в протоколе меняется парадигма пространства имён. Теперь сервера вместо экспорта множественных файловых систем экспортируют одну псевдо-файловую систему собранную из множества реальных файловых систем и что важно, предоставляет новые возможности High-Availability для сетей ЦОД, такие как: прозрачная репликация и перемещение данных, перенаправляя клиента с одного сервера на другой; таким образом позволяя поддерживать глобальное пространство имён, при этом данные находятся и обслуживаются одним выделенным сервером. Это очень тесно взаимосвязано с построением кластерных систем и сильно упрощает их реализацию.NFS v4.1, pNFS — (2010) параллельный NFS позволяет клиентам получать доступ к файлам через «ближайшие» линки без пере-монтирования. В 2012 компании NetApp вместе с RedHat объявляют о сотрудничестве в поддержке pNFS для Clustered Ontap и RHEL 6.2.К преимуществам протоколов работающих поверх IP можно также отнести их возможность маршрутизации, которая дробит широковещательные домены в таких сетях. Для протоколов CIFS 3.0 и NFS 4.0 архитектурно была заложена оптимизация для работы в WAN.

Конвергентные устройства Выпуск конвергентных сетевых коммутаторов, таких как Cisco серии Nexus в 2009 приводит к тому, что их применение объединяет традиционную FC SAN сеть с сетью Ethernet, это позволяет более гибко IT подразделениям отвечать на изменяющиеся потребности бизнеса. Изначально передача 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.

Объектные хранилища поверх Ethernet Объектные хранилища всё больше набирают популярности и в 2013 Seagate выпускает свои объектные жесткие диски Kinetic с Ethernet интерфейсом. А в 2014 компания HGST выпускает свои жесткие диски Open Ethernet.Масштабирование и кластеризация Один из лидеров решений среди NAS кластеризации была компания Spinnaker Networks, начавшая как Start Up и поглощённая компанией NetApp в 2003, её разработки легли в современную ОС Clustered Ontap для СХД NetApp FAS.Наибольшие кластера СХД предоставляющие доступ по блочному протоколу FC достигают 8 нод для NetApp FAS6200/8000, в то время как у конкурентов это обычно не более 4х нод. Для файловых протоколов число нод может быть в разы больше — 24 ноды для NetApp FAS6200/8000 (CIFS, NFS). А для объектных хранилищ число нод теоретически не ограничено. В современном мире, где сравнительно не дорогие кластеризованные ноды с возможностью масштабирования по мере необходимости, могут стать более предпочтительным выбором в отличие от «подхода Mainframe», где используется один дорогой суперкомпьютер.Максимальный размер LUN’а часто может оставлять желать лучшего: достигать 16TB и иметь ограничения по количеству LUN’ов, как на стороне хоста так и со стороны СХД. В кластерезированных СХД этот порог никуда не пропал и для получения большего объема часто применяют решения типа «костыль», объединяя несколько LUN’ов на софтверном уровне на хосте. Файловые шары могут занимать Патабайты и достаточно легко масштабироваться, получая одну огромную логическую сетевую папку в размере нескольких Петабайт, в СХД NetApp FAS это достигается при помощи технологии Infinite Volume с доступом по протоколам CIFS и NFS.

ThinProvitioning & Snapsots Впервые технология snapshot была разработана и внедрена компанией NetApp в 1992, а технология Thin provisioning впервые была представлена в 2001 и впервые представлена в СХД 3Par в 2003 и следом у NetApp FAS в 2004. Несмотря на то, что непосредственного отношения эти две технологии не имеют ни к Ethernet с его CIFS, 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.Хочу отметить, что здесь не рассматривались не распространённые варианты типа IP поверх FC и прочих всевозможных комбинаций протоколов, а только наиболее часто использующиеся комбинаций протоколов в инфраструктурных дизайнах ЦОД, которые и формируют тренды будущего.

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