Унификация транспорта ЦОД

29 июля 2009 LAN
LAN
Июль, 2009 г.
http://www.osp.ru/lan/2009/07/9596544/
Сергей Лебедев, технический руководитель направления "Сетевая инфраструктура ЦОД" , Открытые Технологии

Оптимизация собственной инфраструктуры ИТ позволяет компании значительно сократить издержки и повысить продуктивность. Однако при выборе способов оптимизации сначала следует оценить структуру затрат на поддержание функционирования ЦОД и размещенных в нем бизнес-приложений.

Согласно оценке Uptime Institute, а также на основании опыта российских компаний, расходы на эксплуатацию ЦОД складываются из четырех ключевых составляющих: затраты на электроснабжение (электропитание и кондиционирование), эксплуатацию оборудования (в том числе заработная плата персонала), различные коммунальные услуги (включая аренду помещений) и приобретение расходных материалов. Схематично их соотношение представлено на рисунке.


Как можно видеть, основную долю составляют расходы на электропитание, кондиционирование и эксплуатацию оборудования. Их снижение позволит компаниям значительно сократить совокупную стоимость владения (TCO) ЦОД и уменьшить сроки возврата инвестиций. По данным организации Association for Computer Operations Management (AFCOM), в 2009 г. более 30% компаний планируют сократить бюджеты ЦОД.

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

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

Ниже речь пойдет о новом для рынка решении — технологии унифицированных фабрик (Unified Fabric), внедрение которой позволяет значительно сократить количество необходимых сетевых устройств, а также суммарное энергопотребление и тепловыделение оборудования, помогает упростить кабельную систему, снизить затраты на управление и мониторинг, т.е. в конечном итоге уменьшить совокупную стоимость владения транспортной инфраструктурой.


Откуда что взялось

В классическом ЦОД в качестве транспортной платформы, как правило, используется несколько видов сетей для передачи разных видов трафика. Для доставки пакетов IP применяется технология Ethernet. Сеть хранения данных (SAN) физически изолирована от сети IP, содержит собственные коммутаторы, использует специальные протоколы (Fibre Channel Protocol, SCSI) и обладает отдельной кабельной системой.

В случае кластерных решений для взаимодействия узлов кластера необходима высокопроизводительная среда передачи данных с малыми задержками, поэтому возникает необходимость в построении еще одной сети, например, с применением технологии Infiniband, специализированных коммутаторов, кабелей, разъемов и т.д. В результате в ЦОД существуют как минимум три независимые сети с собственной архитектурой, протоколами, набором оборудования и СКС. Для взаимодействия с каждым типом сети серверы ЦОД должны оснащаться соответствующим набором адаптеров, необходимых (Рисунок 2).

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

Идея объединения различных типов сетей на базе одного вида транспорта появилась достаточно давно. Некоторое время назад наиболее серьезным претендентом на эту роль считалась технология Infiniband, но широкого распространения она не получила и в настоящий момент играет роль нишевого, узкоспециализированного решения. В качестве унифицированного протокола для передачи различных типов трафика рассматривался даже протокол FibreChannel (FC), который на верхнем уровне способен помимо стандартных блоков SCSI переносить и пакеты IP. Но его повсеместному использованию препятствует ряд особенностей — высокая стоимость специализированного оборудования, ограничения на протяженность сети, излишние эксплуатационные затраты.

Наиболее реальным претендентом являлась технология iSCSI, в соответствии с которой блоки протокола SCSI передаются по протоколу TCP/IP по уже построенной инфраструктуре IP. Но помимо преимуществ iSCSI имеет немало недостатков: непредсказуемую (и значительную по меркам сети хранения) задержку; невысокую скорость передачи данных вследствие особенностей функционирования протоколов стека TCP/IP; увеличение нагрузки на центральные процессоры серверов (при этом вычислительные ресурсы отбираются у пользовательских приложений); снижение производительности существующей инфраструктуры IP в результате использования части пропускной способности сети для передачи трафика сети хранения; проблемы с обеспечением безопасности передаваемого трафика.


Вариации на тему Ethernet

Повсеместное использование технологии Ethernet в локальных сетях центров обработки данных, ее активное развитие в плане масштабирования скоростей (сегодня в ЦОД для построения высокоскоростных магистралей широко применяется технология 10GE), появление в ближайшем будущем технологий 40GE/100GE, а в перспективе и терабитовых скоростей, успешное испытание временем и множество хорошо подготовленных в этой области специалистов ИТ заставляют мировое ИТ-сообщество по-новому взглянуть на будущее Ethernet.

Желание производителей оборудования объединить лучшие качества упомянутых выше протоколов привели к появлению технологии под названием Fibre Channel поверх Ethernet (FСoE). Она разрабатывалась под эгидой комитета INCITS T11 и представляет собой стандарт передачи кадров Fibre Channel через сеть Ethernet. Для осуществления передачи трафика Fibre Channel через сеть, построенную на базе Ethernet, кадр FC, включая заголовок, инкапсулируется в кадр Ethernet на стороне передающего устройства и отправляется получателю, который производит деинкапсуляцию исходного кадра FC и его последующую обработку.

Таким образом, с точки зрения техно-логии Ethernet это выглядит как передача еще одного типа протокола верхнего уровня (Fibre Channel) поверх существующей инфраструктуры (Ethernet), а для транспортируемого протокола Ethernet является прозрачной средой передачи оригинальных кадров Fibre Channel. Устройства с поддержкой FC (серверы, дисковые массивы) видят друг друга так, как если бы они находились в единой стандартной сети Fibre Channel, при этом полностью сохраняются идеология и модель управления оригинального FC, включая схему адресации, службы, процессы и сервисы — FLOGI, Name Server, LUN Zoning, LUN Masking, VSAN и т.д. Формат кадра FCoE приведен на Рисунке 3.

FCoE предъявляет к коммутирующей инфраструктуре два основных требования: поддержка кадров большого размера (так называемые Jumbo Frame) и наличие высокоскоростных соединений (от 10 Гбит/с). Это необходимо для того, чтобы кадр FC размером 2112 байт можно было целиком упаковать в кадр Ethernet без дефрагментации, а также обеспечить большую агрегированную скорость для различных типов трафика, передаваемого поверх Ethernet.

Технология FCoE получила широкую поддержку со стороны ведущих производителей оборудования для сетей хранения: Cisco Systems, Emulex, Brocade, EMC, IBM, Intel и Sun Microsystems. Казалось бы, выход найден – Ethernet можно применять в качестве унифицированного транспорта ЦОД, учитывая его скоростные характеристики и возможность переносить кадры FC (c помощью протокола FCoE) без инкапсуляции протоколов стека TCP/IP и дополнительных расходов на передачу большого количества служебных заголовков, как это, например, происходит при использовании технологии FCIP. Но не все так просто.

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


Ethernet для ЦОД

Над вопросом усовершенствования традиционного протокола Ethernet на протяжении ряда лет работали несколько организаций. Итогом их труда стал набор усовершенствований, получивших название Converged Enhanced Ethernet (CEE), Data Center Bridging (DCB) и Cisco Data Center Ethernet (DCE). В их основе лежат одни и те же базовые спецификации, поэтому в определенной степени эти термины можно считать синонимами. Вместе с тем необходимо учитывать, что DCE содержит расширенный набор возможностей по сравнению с CEE/DCB.

Наиболее корректное определение Data Center Ethernet будет выглядеть так: DCE представляет собой архитектуру на базе набора открытых стандартов расширений Ethernet, которая предназначена для улучшения и расширения функционала классического Ethernet в соответствии с требованиями, предъявляемыми к Ethernet как к конвергентному транспорту современного ЦОД.

DCE включает в себя два основных компонента: собственно набор расширений Ethernet и аппаратные средства, обеспечивающие внутреннюю передачу трафика без потерь (так называемый Lossless Ethernet Switch Fabric). Набор расширений DCE содержит как обязательный, так и опциональный функционал.

К обязательному функционалу относятся следующие расширения:

  • механизм управления потоком на основе приоритетов (Priority-based Flow Control, PFC). PFC расширяет функционал стандартного механизма PAUSE (описанного в стандарте IEEE 802.3x). Если механизм PAUSE вызывает прекращение передачи всего трафика по каналу Ethernet, то механизм PFC разделяет его на восемь виртуальных полос (virtual lane) и позволяет управлять передачей трафика на основе приоритетов раздельно для каждой линии. Таким образом можно создать линию без потерь (lossless lane) для чувствительного к потерям трафика (такого как Fibre Channel) и использовать остальные линии в стандартном режиме сброса пакетов для обычного трафика IP. Механизм Priority-based Flow Control описан в стандарте IEEE 802.1Qbb;
  • Enhanced Transmission Selection (ETS) обеспечивает управление разделением пропускной способности консолидированного канала для разных типов линий, решая задачу совместной передачи разных типов трафика без ущерба для качества. Этот инструмент описан в стандарте IEEE 802.1Qaz;
  • Data Center Bridging eXchange (DCBX) отвечает за обнаружение и автоматическое согласование ряда параметров, включая управление полосой и потоком по классам, а также управление перегрузками и логическим состоянием полос. Кроме того, с помощью механизма DCBX взаимодействующие устройства определяют совместимость соседнего устройства с DCE, т.е. очерчивают логическую границу домена DCE в сети ЦОД. Механизм Data Center Bridging eXchange описан в стандарте IEEE 802.1Qaz;
  • Layer 2 Multi-Pathing (L2MP). В отличие от классического протокола Spanning Tree, блокирующего множественные соединения между узлами, механизм L2MP обеспечивает возможность одновременного использования нескольких параллельных путей, благодаря чему пропускная способность расходуется более эффективно. Механизм Layer 2 Multi-Pathing описан в стандарте IEEE 802.1Qau.

К опциональному функционалу относится следующее расширение:

  • Congestion Notification обеспечивает сквозное управление перегрузками с помощью технологий формирования трафика на стороне отправителя информации: при помощи механизма уведомлений технология управления перегрузками посылает специальные сообщения источнику трафика с просьбой замедлить передачу в случае возникновения перегрузок на каком-либо участке сети. Механизм Congestion Notification описан в стандарте IEEE 802.1Qau.

Вторая составляющей архитектуры DCE — "коммутационная фабрика без потерь" (Lossless Ethernet Switch Fabric) — является не менее важной, чем набор расширений Ethernet. Для того чтобы обеспечить реальную передачу по Ethernet без потерь (Lossless Ethernet), необходимо реализовать два обязательных требования: механизм приостановки передачи трафика по каналу в соответствии с классом трафика, такой как PFC, и метод приостановки трафика от входящего к исходящему порту через внутреннюю коммутационную фабрику.

Передача трафика без потерь внутри коммутационной фабрики достигается за счет объединения механизма PFC для приостановки трафика на входном порту коммутатора и механизма управления очередями на выходном порту коммутатора для предотвращения передачи пакетов внутри фабрики в случае недоступности выходного порта (механизм Virtual Output Queues, VOQ). Таким образом, при соблюдении двух упомянутых выше требований реализуется полноценный сквозной Ethernet без потерь. На Рисунке 5 представлен фрагмент конвергентной сети, включающий в себя серверное оборудование и оборудование сети хранения, где для взаимодействия всех устройств используется протокол FCoE. За отсутствие потерь на соединительных каналах отвечает механизм PFC, а технология управления очередями внутри коммутаторов (VOQ) позволяет обеспечить гарантированную передачу пакетов внутри коммутационной фабрики.


Строительные блоки

Какие же именно компоненты потребуются для построения транспортной платформы ЦОД с применением технологий унифицированных фабрик?

Во-первых, необходимы конвергентные коммутаторы с поддержкой технологий 10 Gigabit Ethernet, FCoE и DCE. Раньше других готовое решение для построения консолидированной транспортной платформы представила компания Cisco. Коммутаторы семейства Nexus 5000 оснащены интерфейсами 10GbE, поддерживают технологию FCoE и DCE, а также содержат один или два слота для модулей расширения. Последние позволяют увеличить портовую емкость 10GE/DCE/FCoE либо обеспечить поддержку портов с интерфейсом классического FC. Таким образом, данные коммутаторы могут применяться для консолидации ввода/вывода на уровне доступа ЦОД. Они обеспечивают функционал шлюза между конвергентной и традиционной частями ЦОД и тем самым позволяют осуществлять плавную миграцию от унаследованной инфраструктуры к унифицированной транспортной платформе. Обобщенная схема сети ЦОД, включающая в себя как традиционную, так и конвергентную часть, представлена на Рисунке 6.

Во-вторых, для того чтобы подключить серверы к конвергентной сети, нужны специализированные адаптеры. Они заменяют собой традиционный набор адаптеров локальной сети (Network Interface Card, NIC), адаптеров сети хранения (Host Bus Adapter, HBA) и адаптеров для подключения к сетям межкластерного взаимодействия (Host Channel Adapter, HCA), обеспечивая передачу всех видов трафика через единый унифицированный адаптер ввода/вывода.

Адаптеры могу быть двух видов: специализированный конвергентный адаптер (Convergent Network Adapter, CNA) и обычные сетевые карты Ethernet 10GE с программной реализацией стека FCoE. Адаптер первого типа представляет собой устройство, объединяющее в себе функции стандартного адаптера локальной сети (NIC) и SAN (HBA). Он содержит набор логики обеих карт (NIC и HBA) и специализированный управляющий мультиплексор — фактически это два адаптера в одном. Такое решение позволяет применять набор стандартных драйверов и утилит для установки и администрирования.

Заметим, что, например, операционная система Windows после установки конвергентного адаптера сообщает о наличии в системе двух раздельных логических карт – локальной сети и SAN, хотя в действительности в системе установлен единый конвергентный адаптер. Подобные устройства выпускают компании Emulex и QLogic. Доступные на рынке карты относятся к первому поколению и имеют ряд недостатков, в числе которых — большие размеры, избыточные энергопотребление и тепловыделение, относительно высокая цена. Впрочем, в ближайшее время должны появиться адаптеры второго поколения с унифицированным набором логики, которые будут меньше по размерам, причем ожидается, что энергопотребление и тепловыделение уменьшатся, а цена снизится.

Адаптеры второго типа с програм-мной реализацией стека FСoE отличаются значительно более низкой ценой по сравнению со специализированными конвергентными адаптерами, но производительность их ниже. Кроме того, необходимо учесть возможные проблемы с совместимостью и сертификацией подобного решения.

Относительно требований, предъявляемых к рассмотренным выше компонентам с точки зрения поддержки технологии DCE, можно сказать следующее: коммутатор должен поддерживать Lossless Ethernet Switch Fabric, L2MP, PFC, ETS, DCBX, а конечное устройство (сервер, система хранения и т.п.) — PFC, ETS, DCBX. Поддержка механизма Congestion Notification является опциональной.


Внедрять или не внедрять

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

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

  • уменьшение количества сетевых адаптеров для подключения к сетям различного типа – вместо нескольких адаптеров используется один конвергентный адаптер, который обеспечивает передачу всех типов трафика;
  • сокращение количества необходимых кабельных соединений, коммутационных панелей, органайзеров, лотков и других элементов СКС;
  • снижение количества подключенных портов на коммутирующем оборудовании;
  • уменьшение суммарного энергопотребления и тепловыделения оборудования;
  • повышение коэффициента использования высокоскоростных соединений и элементов транспортной инфраструктуры;
  • снижение совокупной стоимости владения транспортной инфраструктурой.

Для иллюстрации возможных экономических выгод при внедрении и дальнейшей эксплуатации транспортной платформы, построенной с применением технологий унифицированных фабрик, рассмотрим гипотетический ЦОД, где установлено около 200 серверов. Совокупную стоимость владения для традиционной и консолидированной архитектуры сравним исходя из пятилетнего срока эксплуатации. Для расчета воспользуемся фирменной методикой оценки TCO компании Cisco. Во внимание принимаются следующие факторы: стоимость адаптеров, коммутаторов, соединительных кабелей, трансиверов, энергопотребление оборудования, коэффициент переподписки (oversubscription), расходы на сервис, затраты на СКС и электропитание.

Таблица 1 иллюстрирует различие в количественных характеристиках (число портов и коммутаторов, суммарное энергопотребление и т.д.). В Таблице 2 приведено сравнение статей затрат для традиционной и консолидированной архитектуры. Как можно видеть, при использовании технологий унифицированных фабрик совокупная стоимость владения гипотетическим центром обработки данных, содержащим около 200 серверов, за 5 лет владения будет меньше на 230 тыс. долларов по сравнению с традиционным подходом. Рисунок 7 наглядно демонстрирует итоговую разницу в случае традиционной и консолидированной архитектуры.

Подводя итог, можно констатировать, что перспективная технология унифицированных фабрик, где для транспортировки кадров Fibre Channel через сеть Ethernet используется протокол FCoE, а архитектура Data Center Ethernet предоставляет Ethernet без потерь для критичного к потерям трафика, является эффективным средством оптимизации транспортной инфраструктуры ЦОД. Она способствует оперативному реагированию на быстро меняющиеся требования бизнеса и значительному сокращению совокупной стоимости владения транспортной платформой ЦОД. Возможность плавной миграции от традиционной архитектуры к консолидированной обеспечивает взаимодействие компонентов с различными типами подключения, что значительно укрепляет позиции унифицированной архитектуры, поскольку уже сейчас позволяет строить надежный, современный базис для эффективного функционирования корпоративных бизнес-приложений.




Предыдущая новость:
Приложение из ларца
Следующая новость:
Хорошо забытые тонкие клиенты