Как организаторов Ethernet-форума, нас в «Журнале сетевых решений/LAN» радует то, что названная технология находит все больше и больше новых применений. Например, благодаря решениям AVB, уже и профессиональные аудиовизуальные комплексы переходят на бюджетные стандартные сети Ethernet. Но не все происходит просто и гладко. Так, к уже достаточно давно появившимся решениям FCoE многие специалисты продолжают относиться настороженно. Более того, в крупных ЦОД часто сосуществуют даже не две, а три различные сетевые инфраструктуры: Ethernet, Fibre Channel и InfiniBand. В чем причины такого положения дел и каковы перспективы перехода к единой конвергентной инфраструктуре?

 

Как показал опрос, проведенный «Журналом сетевых решений/LAN» в сентябре 2012 года (см. статью автора «Сетевые инфраструктуры ЦОД: текущее состояние и пути развития» в сентябрьском номере «Журнала сетевых решений/LAN» за 2012 год), главная проблема для ИТ-специалистов, занимающихся развитием сетей ЦОД, состоит в необходимости поддержки сразу нескольких инфраструктур. Речь идет о параллельном существовании сетей Ethernet (локальная сеть), Fibre Channel (SAN), а иногда еще и InfiniBand (вычислительный кластер). Почти 40% наших респондентов признали это проблемой. Но при этом лишь четверть опрошенных, то есть почти вдвое меньше, заявили о намерении осуществить конвергенцию локальных сетей и SAN с использованием технологий FCoE и Data Centre Bridging (DCB).

FCOE СОЗРЕЛ …

Чтобы претендовать на роль универсального транспорта и использоваться для передачи трафика FC (FСoE), технология Ethernet должна гарантировать доставку блоков FC/SCSI без потерь (lossless), поскольку этому типу трафика противопоказаны даже минимальные потери, которые в классических сетях Ethernet нередко возникают в случае перегрузки. Необходимые для этого механизмы стандартизованы рабочей группой IEEE 802.1 DCB, набор спецификаций которой составляет основу конвергентных решений Ethernet для ЦОД.

Как считает Александр Скороходов, системный инженер-консультант компании Cisco, представленные сейчас на рынке решения, составляющие экосистему FCoE (коммутаторы, адаптеры, дисковые массивы и т. д.), относятся ко второму или даже третьему поколению продуктов данного типа — это «зрелые», готовые для массового внедрения изделия. К основным преимуществам FCoE он относит сокращение числа соединений (прежде всего на уровне доступа), унификацию транспорта для ЛВС и SAN, а также ускорение доступа к данным в сетях SAN благодаря более высоким скоростям Ethernet.

Сокращение числа портов коммутаторов, серверных адаптеров, трансиверов и кабелей сулит значительное снижение расходов на построение и развитие сети. А унификация транспорта дает возможность использовать однотипные коммутаторы, трансиверы и кабели, в том числе и в тех случаях, когда архитектурные или эксплуатационные соображения диктуют необходимость применения отдельных (выделенных) соединений для ЛВС и SAN. «В результате снижаются число и номенклатура используемых устройств и появляется возможность гибко перераспределять порты между разными системами или, скажем, добавлять конвергентную функциональность к сети, которая первоначально строилась исключительно как ЛВС», — отмечает специалист Cisco.

Что касается скоростей FCoE, то Александр Скороходов приводит в качестве примера коммутатор Nexus 6004, в котором эта технология поддерживается на скорости не только 10G, но и 40G. «Это примерно в три раза выше, чем производительность самого скоростного из доступных интерфейсов Fibre Channel (16G FC), — продолжает он. — Мы ожидаем, что уже в скором будущем на коммутаторах Cisco появятся порты 100GbE с поддержкой FCoE — на то, чтобы преодолеть эту планку, традиционному Fibre Channel потребуется еще много лет». (В FC, в отличие от Ethernet, считается не полезная, а полная скорость битового потока, поэтому, с учетом накладных расходов применяемой для 16G FC схемы кодирования 64b/66b, полезная скорость составляет только 80% от номинальной 16 Гбит/с.)

Достаточно зрелой для применения в ЦОД любого уровня сложности признают технологию FCoE и другие специалисты. Вячеслав Ковалев, начальник отдела ЦОД компании «Открытые Технологии», называет ее главным преимуществом возможность строить крупные гетерогенные сети без чрезмерного увеличения сложности инфраструктуры. Ранее создание раздельных каналов передачи данных с использованием выделенных сетевых адаптеров для FC и Ethernet оборачивалось резким ростом затрат на всю инфраструктуру ЦОД: на закупку сетевого оборудования, расширение кабельного хозяйства, повышение мощности инженерных систем и т. д. Как считает Вячеслав Ковалев, появление решений FCoE позволило по-иному взглянуть на архитектуру построения сетевого сегмента ЦОД, в результате стало возможным сократить затраты на кабельное хозяйство и оборудование как минимум вдвое.

Многие производители пошли по пути встраивания FCoE в свои интегрированные решения. Как рассказывает Александр Гуляев, начальник отдела сетевых проектов компании «Инфосистемы Джет», нередки ситуации, когда заказчик вместе с шасси для блейд-серверов получает оборудование с поддержкой FCoE, хотя первоначально и не предполагал внедрять эту технологию. В результате для использования FCoE достаточно лишь докупить соответствующую лицензию.

… НО БАРЬЕРЫ ОСТАЛИСЬ

К основным препятствиям на пути внедрения FCoE большинство экспертов относят прежде всего сложившиеся организационные особенности ИТ-подразделений заказчиков: как правило, ЛВС и инфраструктуру SAN создают и эксплуатируют разные группы, между которыми существуют непростые отношения и организационные барьеры. Как отмечает Александр Скороходов, обе команды, особенно в крупных организациях, обычно не заинтересованы во внедрении решений, расширяющих зону их ответственности, особенно если это требует изменения порядка эксплуатации инфраструктуры и установления дополнительных взаимосвязей с другой командой. Такое положение дел, кстати, явилось одной из причин того, что транспорт SAN (FCoE) на коммутаторах директорского класса Nexus 7000 всегда вынесен в отдельный логический коммутатор (VDC), дабы обеспечить полную изоляцию зон эксплуатации ЛВС и SAN в рамках одного устройства.

На наличие организационных барьеров указывает и Сергей Гусаров, консультант по сетевым решениям «Dell Россия»: «Технология FC — это отдельный от Ethernet «параллельный» мир со своими принципами построения сетей и их функционирования, своим инструментарием для мониторинга, своими процедурами обслуживания. И до появления конвергентных решений эти миры практически не пересекались. Поэтому в проектах, связанных с конвергенцией сетевой инфраструктуры, необходимо учитывать интересы администраторов разных отделов (сетевого и систем хранения данных) и разграничить зоны ответственности между ними, что в случае с конвергентными сетями не всегда просто сделать. И если технологически решения FCoE уже созрели и позволяют объединить эти две сети, то мировоззрение специалистов, проектирующих и обслуживающих эти сети, еще нуждается в своего рода конвергенции».

Алексей Янкевский, менеджер по развитию бизнеса учебного центра SmartLevel (центр обучения IBS Platformix), основным барьером считает человеческий фактор: «Главная причина — отсутствие грамотных технических специалистов на рынке труда, способных «руками» настраивать FCoE. Внедрение этой технологии требует наличия определенных знаний, а значит, затрат времени и финансовых средств на обучение, а это зачастую идет вразрез с интересами руководства компаний. Важно еще и то, что администраторы SAN и руководители бизнеса говорят на разных языках: первые не могут грамотно аргументировать выгоду от внедрения, вторые не готовы платить деньги за достаточно дорогое оборудование, необходимость которого часто не обоснована. Отдельными пунктами я бы выделил отраслевую специфику и некоторую консервативность конечных заказчиков. Ориентация на облака и облачные услуги заметно сужает список потенциальных пользователей FCoE».

Очевидно, что конвергенция инфраструктуры ЦОД предполагает более тесное взаимодействие подразделений, отвечающих за инфраструктуру хранения данных и сетевую инфраструктуру, а в идеале — их слияние. Но, как отмечает Павел Землянский, главный специалист центра разработки инфраструктурных решений компании «Ай-Теко», процедура взаимодействия подразделений у некоторых заказчиков бывает чрезмерно формализована и сложна, поэтому без помощи ИТ-руководителей, имеющих административные рычаги воздействия на подразделения, внедрение может затянуться.

О проблеме человеческого фактора говорят и другие эксперты. «Администратор традиционной сети хранения данных на базе FC всегда четко понимает, где у него находится SAN A, где — SAN B, какими маршрутами передается трафик от серверов к системам хранения и т. д., — поясняет Роман Седельников, начальник отдела сетевых проектов компании «Техносерв». — В конвергентной фабрике размываются привычные рамки администрирования и, кроме того, накладываются дополнительные ограничения на топологию: например, трафик FCoE требуется передавать через выделенный физический порт в обход группы MLAG».

При переходе к единой сетевой инфраструктуре компании, по сути, «складывают все яйца в одну корзину», и это обстоятельство также может препятствовать внедрению FCoE. «Сеть FC в определенном отношении даже более критична, чем Ethernet. В ней пакеты не только не должны теряться, но и не должно быть серьезных задержек при коммутации трафика. Поэтому многие заказчики предпочитают заплатить за две не связанные между собой сети, считая, что лучше быть немного консервативным, чем повысить риск потери данных», — считает Сергей Гусаков, технический директор компании Extreme Networks.

Как уже говорилось, за счет сокращения числа коммутаторов, сетевых карт в серверах и кабельных подключений конвергентные решения должны быть дешевле, но на деле это не всегда так. Как отмечает Сергей Гусаров, при определении стоимости полного решения FCoE необходимо учесть затраты не только на сетевую инфраструктуру, реализующую функционал DCB, но и на необходимые программные лицензии для нее. На практике оказывается, что для небольших ЦОД традиционные решения на основе выделенной ЛВС и выделенных коммутаторов Fibre Channel для SAN обходятся дешевле конвергентных.

На тонкости исчисления затрат обращает внимание и Александр Гуляев: «Конвергенция реализована только на высокоскоростных (10G) каналах, а сам функционал, как правило, лицензируется — естественно, не бесплатно. Между тем вполне может оказаться, что заказчику достаточно гигабитной ЛВС и отдельной SAN для относительно небольшого числа серверов, а такое решение будет даже дешевле конвергентного».

По мнению Дамира Артыкова, руководителя отдела сетевых решений «НР Россия», применение протоколов передачи данных с высокими требованиями к скорости и надежности (к которым в первую очередь можно отнести FC) целесообразно пока лишь в довольно узком сегменте ИТ-инфраструктур, где требуются большие системы хранения данных. Применение подобных СХД, в свою очередь, оправданно только в случае высокой концентрации вычислительных ресурсов, например в центрах обработки данных.

«Для ЦОД характерно расположение всех бизнес-критичных ресурсов на локальных площадках — это может быть отдельное здание или группа близко расположенных зданий. При этом не ставится задача передачи трафика между серверами и СХД на большие расстояния и, соответственно, пока конкуренция между технологиями FC и FCoE не столь актуальна, — считает Дамир Артыков. — Подобная дискуссия будет иметь больший смысл с развитием облачных инфраструктур и дальнейшим совершенствованием технологии FCoE (в части скоростей передачи данных и стандартизации передачи трафика FCoE по многозвенным линиям — multihop FCoE), а также со снижением стоимости владения технологии FCoE в пересчете на сетевой порт».

СЦЕНАРИИ ПЕРЕХОДА НА FCOE

На практике технология FCoE чаще всего используется для конвергенции на уровне доступа. «Заказчиков, выбравших комплексное (end-to-end) решение FCoE [когда все компоненты сети, включая серверы, коммутаторы и СХД, работают по FCoE], меньше, чем тех, кто использует конвергенцию на уровне ввода-вывода серверов. Чаще всего ими интересуются компании, которые строят крупные ЦОД с нуля, — рассказывает Сергей Гусаров. — Большинство же заказчиков, имеющих крупные сети хранения данных, используют коммутаторы Fibre Channel, их в первую очередь привлекает конвергенция на уровне доступа, когда серверы подключаются к имеющейся фабрике FC через конвергентные коммутаторы уровня доступа. Интересу также способствует то, что практически все адаптеры 10GbE, которыми сегодня комплектуются серверы, являются конвергентными».

Большинство экспертов рекомендуют начинать переход на конвергентную инфраструктуру FCoE именно с подключения серверов к коммутаторам доступа и интеграции с имеющейся у заказчика фабрикой Fibre Channel. «В ситуации, типичной для наших заказчиков, я бы рекомендовал постепенно избавляться от использования FC на уровне доступа, а в качестве первого шага использовать для подключения серверов конвергентные решения ToR [Top of Rack — коммутаторы, устанавливаемые в верхней части каждой стойки], которые, в свою очередь, подключаются к существующему ядру SAN по FC, — делится своим опытом Александр Гуляев. — Это позволит избежать необходимости единовременных масштабных инвестиций и обеспечить нормальную работу инфраструктуры во время переходного периода».

Специалисты компании HP предлагают несколько вариантов внедрения FCoE. Самый простой способ подключения серверной фермы (virtualized blade servers) к сетям передачи и хранения данных основан на применении конвергентных сетевых адаптеров семейства HP Virtual Connect FlexFabric. Например, 24-портовый модуль позволит обеспечить доступ серверной фермы к различным сетям по каналам 10 Гбит/с без какой-либо перестройки существующих сетей (см. Рисунок 1).

Рисунок 1. Подключение серверной фермы к сети передачи и сети хранения данных с применением конвергентных сетевых адаптеров HP Virtual Connect FlexFabric.
Рисунок 1. Подключение серверной фермы к сети передачи и сети хранения данных с применением конвергентных сетевых адаптеров HP Virtual Connect FlexFabric.

 

Вариант с использованием FCoE на уровне доступа (см. Рисунок 2) позволяет максимально защитить инвестиции в уже имеющуюся инфраструктуру, включая установленные серверы с адаптерами HBA и сетевыми картами NIC. В то же время при развертывании новых серверов, с конвергентными адаптерами CNA, можно в полной мере сэкономить на оборудовании, а в будущем сократить и операционные расходы (меньше энергопотребление, тепловыделение, проще управление и пр.).

Рисунок 2. Вариант с внедрением FCoE на уровне доступа.
Рисунок 2. Вариант с внедрением FCoE на уровне доступа.

 

Более масштабное внедрение предполагает использование коммутаторов с поддержкой FCoE разного уровня, включая устройство для ядра сети (см. Рисунок 3). В этом случае дополнительно предлагается задействовать коммутатор, который наряду с FCoE позволяет подключаться по обычным каналам FC. Подобное решение обеспечит все необходимое для интеграции традиционных систем, а также максимальную гибкость для дальнейшего развития. Стоит также отметить, что HP рекомендует использовать коммутаторы, поддерживающие протокол TRILL (подробнее о нем см. статью автора ««Фабрики» — ЦОДам» в январском номере «Журнала сетевых решений/LAN» за этот год).

Рисунок 3. Вариант с комплексным (end-to-end) внедрением FCoE и интеграцией в имеющуюся сеть FC.
Рисунок 3. Вариант с комплексным (end-to-end) внедрением FCoE и интеграцией в имеющуюся сеть FC.

 

ВАРИАНТ С ISCSI

Говоря о перспективах перехода в ЦОД на единую сетевую инфраструктуру Ethernet, нельзя забывать и о другой технологии передачи трафика СХД по Ethernet (точнее, по TCP/IP) — iSCSI. Как показал упомянутый выше опрос «Журнала сетевых решений/LAN», если технологию Fibre Channel используют 67% наших респондентов, то iSCSI — 36% (см. Рисунок 4). Невысокая стоимость делает iSCSI привлекательным решением для слабонагруженных и некритичных серверов, которым необходим блочный доступ.

Конвергенция в сетях… и в умах
Рисунок 4. Результаты ответа на вопрос «Какие технологии применяются для подключения систем хранения?», полученные в ходе опроса, проведенного «Журналом сетевых решений/LAN» в сентябре 2012 года.

 

Реализация iSCSI, в отличие от FCoE, не требует дополнительных инвестиций в имеющуюся инфраструктуру ЦОД, отмечает Павел Землянский из «Ай-Теко», поскольку используются обычные коммутаторы Ethernet, тогда как для внедрения FCoE нужна сетевая инфраструктура Lossless Ethernet. По его мнению, если основная область применения FCoE — крупные ЦОД, то iSCSI незаменима для построения инфраструктуры небольших центров обработки данных предприятий среднего размера, для которых скорость обмена данными не так критична, как стоимость реализации.

По мнению Сергея Гусарова, технология iSCSI — идеальный вариант для небольших компаний, где нет инфраструктуры FC и специалистов с опытом ее эксплуатации, поскольку она предполагает использование доступных коммутаторов, простые процедуры настройки и обслуживания сети. Он отмечает, что если при традиционном подходе обычно устанавливают отдельные коммутаторы для iSCSI SAN и ЛВС, то благодаря поддержке технологии DCB и ее расширения для iSCSI появилась возможность строить одну общую сеть. Например, Dell предлагает комплексное решение на основе СХД Dell EqualLogic, коммутаторов Dell Networking и серверов Dell PowerEdge, все компоненты которого поддерживают технологию iSCSI DCB. Решение позволяет отказаться от установки выделенных коммутаторов для iSCSI (и тем самым сэкономить средства) благодаря использованию единых конвергентных коммутаторов 10GbE, которые поддерживают трафик ЛВС и iSCSI, обеспечивая при этом передачу трафика iSCSI без потерь.

По словам Евгения Вострикова, ведущего инженера компании «Техносерв», технология iSCSI также хорошо зарекомендовала себя при организации удаленных хранилищ данных и репликации информации между географически распределенными ЦОД через обычные сети IP, так как в этом случае не требуется выделять каналы связи между ЦОД.

Поскольку iSCSI работает поверх протоколов TCP/IP (см. Рисунок 5), функциональные особенности указанных протоколов ограничивают возможности построенной на ее базе сети хранения данных. Наличие стека TCP/IP неизбежно сказывается на производительности сети, а также повышает нагрузку на центральный процессор. Поэтому iSCSI лучше использовать там, где требования к пропускной способности не очень критичны. Там же, где компромиссы недопустимы, лучше ориентироваться на FC и/или FCoE.

Рисунок 5. Сравнение iSCSI и FCoE.
Рисунок 5. Сравнение iSCSI и FCoE.

 

Немало специалистов считают, что при переводе трафика СХД в сети Ethernet большей популярностью будут пользоваться те технологии, где используется «чистый» Ethernet, — такие как iSCSI и NFS. Так, в частности, полагает Сергей Гусаков: «Уже сейчас ряд систем хранения на базе технологий iSCSI и NFS показывают на 30% большую пропускную способность, чем их конкуренты, использующие FC и FCoE. Вероятнее всего, переход [систем хранения] на Ethernet будет происходить благодаря развитию технологий iSCSI и NFS и постепенному вытеснению технологий FC и FCoE. Но путь этот долгий — прежде всего из-за критичности данных, передаваемых через сеть FC, и некоторого консерватизма ИТ-специалистов».

IBOE КАК НОВЫЙ ВИТОК КОНВЕРГЕНЦИИ

Помимо Ethernet и FC, в ЦОД, особенно в крупных, используется еще одна сетевая технология InfiniBand — в основном для организации высокопроизводительных кластеров (HPC). Каковы перспективы перевода трафика InfiniBand в сети Ethernet? Хотя официального термина IBoE не существует, соответствующее решение имеется и называется RDMA over Ethernet (RoE). Спецификация для этой технологии была принята организацией InfiniBand Trade Association (IBTA) еще в 2010 году. Многие эксперты полагают, что название IBoE более точно отражало бы смысл этой технологии, но IBTA, видимо по политическим соображениям, ввела в обиход иной термин.

Удаленный прямой доступ к памяти — так расшифровывается название технологии RDMA — позволяет передавать данные между серверами напрямую из памяти одного приложения в память другого без участия центральных процессоров. Решения RoE (иногда используется термин RoCE — RDMA over Converged Ethernet), обеспечивают передачу данных с очень низкой задержкой в сетях Ethernet без потерь.

Технология RoCE реализована, в частности, компанией Mellanox Technologies в адаптерах ConnectX-2 EN, что стало ответом этого производителя систем InfiniBand на рост «популярности конвергенции сетевых инфраструктур на базе надежной технологии Ethernet». «Мы предлагаем решения IBoE для создания распределенных IB-фабрик, чтобы преодолеть ограничения стандартных каналов передачи данных при использовании IB, — отмечает Константин Баканович, технический директор компании DSCon, дистрибьютора решений Mellanox Technologies. — В то же время IBoE имеет довольно специфическую реализацию и, конечно, не может заменить IB при решении классических задач, например при организации межузлового взаимодействия в высокопроизводительном кластере».

Адаптеры Mellanox с поддержкой IBoE/RoCE используются и другими производителями. Так, Cisco предлагает комплексное решение на основе серверов Cisco UCS, коммутаторов Cisco Nexus и адаптеров Mellanox ConnectX-2 EN в первую очередь для заказчиков, работающих в сфере алгоритмической торговли на финансовых рынках.

Если IBoE/RoCE является неким аналогом FCoE в мире систем HPC, то аналогом iSCSI служит технология iWARP. «IBoE/RoCE и iWARP решают близкие задачи, но опираются на разные подходы и допущения относительно сетевой инфраструктуры», — объясняет Александр Скороходов. Плюсом iWARP служит отсутствие специальных требований к инфраструктуре, преимуществом RoCE — использование потенциала DCB для предотвращения потерь сообщений (и связанной с этим необходимости повторной передачи данных), а также сохранение логики транспортного и сетевого уровня InfiniBand.

Тесты показывают, что если iWARP примерно в два раза быстрее классических систем TCP/IP, то RoCE во столько же раз быстрее iWARP (см. Таблицу 1). «IBoE опирается на проверенный транспорт InfiniBand и прозрачен для уже написанного программного обеспечения, — добавляет Евгений Востриков. — iWARP же базируется на транспорте TCP, со свойственными ему ограничениями, и для его использования потребуется адаптация программных продуктов HPC».

 

Таблица 1. Сравнение задержки при передаче трафика между двумя портами при использовании различных технологий.
Размер пакета, байт Задержка при использовании TCP/IP и 10G, мкс Задержка при использовании iWARP и 10G, мкс Задержка при использовании RoCE и 10G, мкс
64 19,47 9,84 4,05
128 19,13 10,11 5,30
256 20,08 10,40 5,44
512 21,08 10,93 5,71
1024 23,67 12,31 7,07
Источник: Cisco Systems

  

По мнению Евгения Вострикова, технология IBoE на данный момент не может заменить InfiniBand по причине ограниченной поддержки со стороны производителей коммутаторов, а также из-за высокой цены, не предполагающей особой выгоды по сравнению с традиционной InfiniBand. Однако в будущем она вполне может позволить консолидировать трафик HPC с трафиком сетей хранения и сетевым трафиком в конвергентных сетях.

Сергей Гусаков предрекает InfiniBand не слишком радужное будущее: «Вполне вероятно, что, как и многие технологии, для которых Ethernet вдруг становится транспортом, InfiniBand начнет потихоньку терять и без того не особенно крепкие позиции и скоро мы увидим закат данной технологии». Среди недостатков InfiniBand специалист компании Extreme отмечает более высокие капитальные (CAPEX) и эксплуатационные (OPEX) расходы на построение и содержание соответствующей инфраструктуры. Так, CAPEX для InfiniBand складывается из стоимости самой инфраструктуры InfiniBand, стоимости коммутатора Ethernet для управления, а также стоимости шлюза Ethernet для маршрутизации трафика «во внешний мир». При расчете операционных расходов, которые для гетерогенной сети очевидно выше, необходимо еще учитывать оплату труда специалистов по InfiniBand, которых на рынке мало. Кроме того, он предупреждает, что «рынок InfiniBand на 90% контролируется одним производителем», а значит, существует риск зависимости от него.

ETHERNET — НАШЕ ВСЕ?

Ethernet — универсальная технология, но далеко не всегда и во всем она оказывается лучшей. «Наличие на рынке таких решений, как IBoE и iWARP, позволяет говорить о том, что нишевые решения живы и будут применяться и далее, — говорит Александр Гуляев из компании «Инфосистемы Джет». — Кроме создания инфраструкутур с отдельными выдающимися характеристиками, их немаловажная роль состоит в том, чтобы своим примером стимулировать дальнейшее развитие Ethernet в направлении еще не занятых им сегментов инфраструктуры, в так называемые нишевые области».

Как полагает Константин Баканович, в ближайшей перспективе высокопроизводительный Ethernet все больше и больше будет претендовать на то, чтобы стать основным и, возможно, единственным транспортом для передачи трафика приложений, трафика хранения данных и межузловых взаимодействий в HPC. «Однако говорить о том, что Ethernet полностью вытеснит все остальные протоколы, такие как, например, FC, все еще прежде-

временно. На практике в тех случаях, где требуется высокая, а зачастую и предельная производительность, такие протоколы, как FC и IB, все еще остаются вне конкуренции благодаря очень высокому уровню производительности, надежности и управляемости», — считает специалист DSCon.

Павел Землянский напоминает, что в территориально распределенных сетях процесс вытеснения технологией Ethernet «классических» WAN-протоколов канального уровня начался около десяти лет назад и до сих пор не окончен. Поэтому, считает он, о построении центров обработки данных, в которых на всех интерфейсах обмена данными будет использоваться Ethernet, в ближайшей пятилетке мы вряд ли услышим, поскольку переход к конвергентной инфраструктуре в ЦОД только начинается.

Итак, универсализм Ethernet, широкая распространенность и относительно невысокая стоимость соответствующих решений способствуют все более широкому их распространению и «захвату» ими все новых областей. Однако конвергенция «всего и вся» на базе Ethernet не случится в одночасье. И Fibre Channel, и InfiniBand использовались, используются и будут использоваться. Однако присутствие на рынке достаточно зрелых решений FCoE и IBoE дает заказчикам возможность задействовать их преимущества в новых инсталляциях. И очень часто это приносит существенную экономию средств, снижает сложность сети, повышает ее гибкость, а также оптимизирует для использования виртуализации и развертывания облачных сервисов.

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.