Сети в облаках

Как мы дошли до жизни такой?

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

Этап N-1. В формировании требований к инфраструктуре тон задают производители программного обеспечения: в том или ином объеме оно требуется любой компании в соответствии с потребностями бизнеса. При приобретении ПО выполняется расчет необходимой вычислительной мощности (sizing) и закупается оборудование. Как правило, именно то, которое протестировано с этим ПО и рекомендовано производителем. Далее этим оборудованием заполняются стойки в серверных помещениях. Когда стоек не хватает – строятся другие серверные, когда выясняется, что бизнес может пострадать от потери ЦОДа – строят резервный ЦОД, который заполняется все теми же серверами.

Не правда ли, очень привычная картина? Подход «каждой системе – свои отдельные серверы». В России ее можно наблюдать в ЦОДах подавляющего большинства компаний.

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

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

Соответственно, борьба за «дивный новый мир» пошла в следующих направлениях:

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

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

А виртуализировать, как выяснилось, можно практически все: серверы, системы хранения, доступа, телефонные сервисы. И даже сети.

Этап N. Первыми орга-низациями, которые от осознания перешли к конкретным действиям, стали стремительно развивающиеся Интернет-компании, ориентированные на немыслимые для эпохи N-1 темпы роста клиентской базы и связанные с этим требования к инфраструктуре, которая должна обеспечить обслуживание каждого первого запроса1. Не случайно, что до сих пор многие из этих компаний в качестве платформ используют собственные разработки и know-how, ведь на момент старта их проектов на рынке просто не было готовых решений под их нужды.

Затем появились первые поставщики облачных услуг, продуктами которых стали доступные для аренды виртуализованные серверы и ПО.

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

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

Из основных технологических результатов нового подхода к созданию ИТ-инфраструктуры можно выделить следующие:

• увеличение доли использования mid-range и Blade-серверов в качестве основных «кирпичиков» вычислительной инфраструктуры (снижение доли High-End);
• существенное увеличение утилизации серверов и сетевых соединений в ЦОДе;
• появление и внедрение корпоративного и операторского прикладного ПО, работающего в условиях виртуализованных сред;
• появление систем управления и оркестрации сервисов инфраструктуры, превращающих набор виртуализованных серверов в системы предоставления «облачных» услуг SaaS, IaaS, PaaS;
• упрощение физической инфраструктуры ЦОДа с одновременным усложнением ее логической составляющей;
• дальнейшая консолидация инфраструктуры и появление конвергентных решений (например, на базе FCoE);
• интеграция сетевой инфраструктуры с гипервизорами и «облачными» системами управления на уровне EMS/NMS или отдельных устройств;
• анонсы появления виртуализованных сетевых сервисов (virtual WAAS, virtual firewall, virtual load balancing и т. д.).

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

Рассмотрим подробнее, что представляют собой современные сетевые решения для дата-центров.

Облако в сети

Что же такого экстраординарного могут ожидать заказчики от сетевых продуктов для дата-центров?

Ответ проще всего представить в виде таблицы 1.

Табл. 1. Особенности сетевых продуктов для современных ЦОДов

Как видно из таблицы, заявлен целый комплекс инновационного функционала, делающего сетевые продукты уникальными и востребованными для построения современных высокоэффективных «облачных» дата-центров.

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

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

Исходя из вышесказанного, неизбежно появляются два вопроса:

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

Внутри облачной сети

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

Надежность сети

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

Разработанный около 30 лет назад протокол Ethernet2 подвергался различным улучшениям на протяжении всего этого времени, но главному в своей природе не изменил – он не гарантирует надежной доставки данных. Сеть может «терять» передаваемые пакеты при возникновении перегрузок (congestions) на отдельных участках. Гарантию доставки данных обеспечивают протоколы следующих уровней сетевой модели (в частности, протокол TCP). Но для функционирования ЦОДа, где важна минимальная задержка и предполагается эффективная работа протоколов сетей хранения данных, необходима гарантия доставки пакетов на канальном уровне, т.е. на уровне Ethernet.

Для решения этой задачи применяют новую среду передачи данных, называемую Data Center Bridging (DCB). Основным отличием среды DCB от классического Ethernet является механизм Flow Control с расширенными возможностями, служащий для гарантированной доставки различных видов трафика.

Работу этого механизма обеспечивают следующие протоколы:

• Priority-based Flow Control (PFC, 802.1Qbb). В среде DCB передача трафика осуществляется с использованием до восьми виртуальных каналов. PFC позволяет динамически контролировать передачу данных между двумя соседними устройствами, запуская или останавливая трафик на канале, который испытывает перегрузку (в конце статьи приведены основные используемые термины);
• Enhanced Transmission Selection (ETS, 802.1Qaz). Отвечает за выделение полосы пропускания для виртуальных каналов DCB, что позволяет разделить общую полосу пропускания на части для каждого типа трафика;
• Data Center Bridging Exchange (DCBX). DCBX позволяет двум сторонам обмениваться PFC и ETS атрибутами, а также служебной информацией протокола FCoE.
  Взамен протоколов семейства xSTP в сетях дата-центров для обеспечения отказоустойчивости за счет резервирования соединений применяются решения на базе стандарта Transparent Interconnection of Lots of Links (TRILL), разработанного институтом IETF. TRILL использует механизм инкапсуляции для всех типов входящего трафика, попадающего в сеть, что позволяет:
• передавать трафик по всем эквивалентным путям одновременно в режиме балансировки по маршрутам c одинаковыми метриками (ECMP4);
• обеспечивать коммутацию трафика FCoE в режиме multihop;
• обеспечивать практически моментальную переконфигурацию сети по сравнению со случаем использования классических протоколов, применяемых для обеспечения отказоустойчивости (семейство протоколов хSTP – RSTP, MSTP, PVSTP, PVST+).

Масштабируемость

Для легкой масштабируемости уровня доступа сети и организации эффективного по стоимости подключения серверов чаще всего применяется двухуровневая топология доступ–агрегация на базе фиксированных устройств с универсальными портами 1/10G формата SFP/SFP+.

Такую топологию в литературе называют fat tree или clos topology5 (см. рис. 1). Она обеспечивает фиксированную задержку при передаче данных между устройствами, подключенными к разным коммутаторам, и множество маршрутов с одинаковым количеством промежуточных устройств (метрикой). Топология позволяет достаточно просто изменять коэффициент переподписки в сети и создавать сеть с десятками коммутаторов доступа и сотнями портов для подключения серверов.

Другой возможный, но очень специфический вариант топологии сети дата-центра – так называемая полносвязная топология, или full mesh (см. рис. 2). Основным достоинством такой топологии является возможность достижения минимального времени задержки при передаче пакетов, т. к. максимальное число промежуточных узлов в такой сети доступа – два (в топологии fat tree – 3 узла). Эту топологию можно применять в том случае, если сегмент сети относительно невелик (4–6 коммутаторов), и требуется минимизация такого параметра, как время задержки прохождения фрейма.

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

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

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

К счастью, эволюция физических интерфейсов Ethernet на 10 Гбит/c не закончилась. Уже сейчас в коммутаторах некоторых производителей появляются 40G и 100G интерфейсы. С учетом их наличия гипотетическая6 архитектура сети ЦОДа будущего может выглядеть так, как это продемонстрировано на рис. 3.

Следует отметить, что объемы данных в современном ЦОДе могут быть достаточно велики, но совсем не обязательно драматичны. Поэтому прежде чем планировать приобретение дорогостоящего оборудования с 40/100G интерфейсами, необходимо просчитать необходимость подобных затрат: может оказаться, что возможностей 10G интерфейсов будет достаточно.

Рис. 1. Пример архитектуры сети ЦОДа на базе топологии типа «доступ–агрегация»

Конвергенция

Современная сеть дата-центра позволяет передавать традиционный сетевой трафик данных и трафик протокола СХД Fibre Channel через один и тот же канал 10 Гбит/с, которым сервер подключен к сети.

Для передачи трафик FC инкапсулируется в Ethernet-фреймы большого размера (используется отдельный FCoE ethertype) и передаются от сервера через коммутатор и далее по сети к устройству хранения данных. Протокол, обеспечивающий конвергенцию, – FCoE (Fibre Channel Over Ethernet), разработан комитетом T11 института IETF, который разрабатывал все стандарты Fibre Channel.

Современные устройства, поддерживающие конвергенцию7, могут передавать FCoE трафик через цепочку коммутаторов (функционал FCoE multihopping), что позволяет эффективно организовать сеть дата-центра с минимальными требованиями к количеству портов в FC-сегменте, вплоть до полного отсутствия FC-сегмента: уже сейчас коммерчески доступны СХД с 10G FCoE интерфейсами8, которые могут подключаться непосредственно в конвергентные порты.

Также существуют модели коммутаторов, которые позволяют стыковать конвергентную Ethernet-сеть с существующим FC-сегментом и обеспечивать полноценное включение конвергентных устройств в FC-фабрику. Такие устройства имеют на борту Fibre Channel интерфейсы формата SFP.

Варианты архитектуры конвергентной сети, построенной на коммутаторах, поддерживающих FCoE multihopping, представлены на рис. 4. Конвергентная сеть состыкована с СХД через пару отдельных конвергентных коммутаторов с портами Fibre Channel, выполняющих функции шлюза между сетями. Такая архитектура предоставляет наибольшую гибкость при использовании сетевых Fibre Channel хранилищ в облачных ЦОДах, т.к. позволяет относительно дешево обеспечить быстрый доступ к СХД и ЛВС для каждого сервера в «облаке». Это делает «облачную» вычислительную инфраструктуру более универсальной.

Управление

В этой области традиционно нет сложившихся стандартов, производители предлагают свои собственные, как правило, несовместимые решения.

Для эффективного управления набором фиксированных коммутаторов, из которых состоит сеть современного дата-центра, могут применяться технологии логического шасси или Fabric Extenders9. В случае логического шасси управление набором устройств осуществляется как одним большим виртуальным коммутатором, и администратор настраивает всю сеть путем подключения к одному IP-адресу. При использовании Fabric Extenders все настройки выполняются на головном устройстве, к которому подключаются экстендеры.

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

Экономика

Экономический аспект применения современных решений обеспечивается следующими их характеристиками:

• возможность стандартного дешевого подключения серверов к 10G портам коммутаторов с помощью медных кабелей типа Twinax или оптических Active Optic Cable (до 10 раз дешевле, чем с использованием SFP+ оптических модулей);
• возможность лицензирования количества активированных портов на коммутаторах. Вы можете купить минимальное количество портов, а затем увеличить это число покупкой лицензии без замены оборудования;
• отдельное лицензирование функционала, в частности, FCoE, обычно приобрета-
  ется отдельной лицензией;
• сокращение количества портов СКС, необходимых для инсталляции в дата-центре. Соответственно, снижаются требования к размерам кроссов, освобождается дорогостоящее место в дата-центре;
• снижение энергопотребления за счет сокращения числа активных сетевых устройств;
• снижение затрат на эксплуатацию единой конвергентной сети в отличие от эксплуатации двух отдельных сетей ЛВС и СХД.

Отрицательным моментом в экономике таких решений является необходимость приобретения 10GbE конвергентных сетевых адаптеров (CNA), стоимость которых может быть достаточно высока.

Виртуализация сетевого доступа и интеграция с вычислительной инфраструктурой

Решения для виртуализации сетевого доступа в настоящее время мало стандартизированы, как и любая задача, в которой используются разные системы,
да еще и разных производителей.

Между тем, набор задач и проблем здесь достаточно велик:

• необходимость изменения параметров (VLAN, QOS, ACL и т. д.) сетевого порта при миграции виртуальной машины с одного физического сервера на другой;
• разгрузка CPU виртуализованного сервера, который, помимо прочего, вынужден решать задачи обмена сетевым трафиком между виртуальными машинами как внутри системы виртуализации, так и с внешним миром;
• наблюдение, аудит и фильтрация трафика виртуальных машин, который не выходит за пределы физического сервера, например, с помощью решений IPS или firewall.

Предлагаемый производителями спектр решений включает:

• специализированные сетевые адаптеры для виртуализированных сред (поддержка SR-IOV10 или других методов виртуализации ресурсов, VMOP11 , VEB12 , VEPA13);
• распределенные виртуальные коммутаторы, интегрированные со средой виртуализации (Cisco Nexus 1000V);
• расширение архитектуры Cisco Fabric Extender до уровня виртуальной машины (технология VM-FEX) на базе пре-стандартной реализации протокола IEEE 802.1Qbh (VNTag);
• интеграция со средой виртуализации для определения миграции виртуальных машин и применения соответствующих настроек на физических портах;
• применение профилей для портов доступа коммутаторов на базе MAC-адресов виртуальных машин (Brocade AMPP).

Список этот далеко не полон и будет пополняться в ходе усовершенствования данного класса решений, которые сейчас находятся в самом начале своего развития.

Поставщики решений

Наиболее полные и функциональные решения для сетей дата-центров в настоящее время предлагают компании Cisco и Brocade.

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

Заказчики в облаках

Вопрос «что делать?» – последний и самый важный. Как же сейчас поступить заказчику, который хочет построить новый ЦОД? Какое решение выбрать?

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

1. Прежде всего: строить сеть ЦОДа на устаревшем оборудовании и прежних принципах – весьма спорное вложение денег, особенно если ЦОД строится на перспективу, и в него планируется закупать новое серверное оборудование, а не перевозить устаревшие машины из другого ЦОДа.
2. Определитесь, какие именно сервисы вам обязательно необходимы, а какие – во вторую очередь. Рассматривайте и сравнивайте предложения ведущих производителей через призму именно ваших потребностей.
3. Хорошим вариантом будет создание сети на базе новых решений, без внедрения отдельных сервисов, которые на данном этапе вызывают вопросы. Например, сеть будет отлично справляться со своими обязанностями коммутации Ethernet и без конвергенции: функционал FCoE открывается дополнительной лицензией, и на первом этапе ее можно не покупать. Добавить этот функционал вместе с лицензией можно будет впоследствии.
4. Продумайте схему эксплуатации нового ЦОДа. Внедрение конвергентных решений может стать причиной конфликта в организации, в которой различные люди эксплуатируют отдельные сети передачи данных и СХД.
5. Определитесь с типом и конфигурацией серверов – Rack- или Blade-серверы.
   В зависимости от этого у вас в сети может появиться еще один архитектурный уровень – коммутаторы Blade-серверов, которые могут быть совсем другого производителя и не поддерживать необходимые функции.
6. Обратитесь за помощью к интегратору. Компания «Инфосистемы Джет» предлагает вам ознакомиться с современными конвергентными решениями на демо-стенде, развернутом в нашей лаборатории.

В качестве эпилога: прояснение ландшафта и разгон облаков

Несмотря на высокое функциональное наполнение и инновационный задел новых сетевых решений, они находятся в начале своего пути к заказчику.

Прежде всего, их потребителями будут компании, которые создают частные, или приватные «облачные» инфраструктуры для своих нужд или для предоставления сервисов своим клиентам, крупные корпоративные заказчики и операторы связи.

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

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

Если вернуться к началу статьи, можно найти тезис, что упрощение физической инфраструктуры в ЦОДе сопровождается ростом логической сложности создаваемых систем.

Это означает, что работа по созданию и поддержке подобных решений для системных интеграторов, таких, как «Инфосистемы Джет», всегда найдется.