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

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

 

Рисунок 1. Архитектура ЦОД следующего поколения.

 

Эти тенденции оказали большое влияние на архитектуру коммутирующих модулей (Switch Fabric), которые теперь должны поддерживать крупные сети второго уровня (Layer 2, L2), поскольку виртуализация и мобильность серверов, новые протоколы хранения и так называемая межпроцессная коммуникация с минимальными задержками располагаются в одних и тех же доменах второго уровня. Кроме того, новая инфраструктура ЦОД призвана уменьшить сложность администрирования систем, причем возможность использования технологии виртуализации необходимо предусмотреть еще на стадии проектирования. Рабочая группа IEEE Data Center Bridging Group занимается вопросами расширения Ethernet с целью поддержки вышеупомянутых тенденций и заимствовала многие технологии, знакомые по технологии Infiniband: изоляцию классов (Class Isolation), минимальные задержки (Low Latency), виртуализацию ввода/вывода и коммутаторов, технологию потоков трафика без потерь (Lossless Traffic Flow), контроль перегрузки (Congestion Control) и маршрутизацию второго уровня с множественными путями (Multipath L2 Routing). Все они поддерживаются стандартами Converged Enhanced Ethernet (CEE) и Data Center Ethernet (DCE). Заботясь о дальнейшем повышении эффективности ЦОД, многие предприятия ищут способы повышения экономической рентабельности своих центров. Несколько мелких ЦОД можно объединить в более крупные, а во многих случаях обращение у услугам коммерческих «облачных» провайдеров оказывается выгоднее, чем содержание собственного ЦОД. Предприятия, предоставляющие подобные услуги, на одной площадке создают и обслуживают несколько виртуальных ЦОД. В связи с этим в будущем ожидается еще больший рост числа внешних (Public) и внутренних облаков (Private Cloud).

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

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

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

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

Таким образом, сети будущих ЦОД отличаются от нынешних следующими характеристиками:

  • наличие подключений для большого количества компьютерных узлов при высокой плотности их размещения;
  • снижение потребляемой мощности;
  • повышение пропускной способности портов;
  • уменьшение агрегации каналов между конечными точками;
  • сокращение задержек и прогнозируемое поведение;
  • увеличение размеров сегментов второго уровня с меньшим объемом коммутации;
  • изоляция сегментов и поддержка классов сервиса (Class of Service, CoS);
  • виртуализация.

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

Традиционные центры обработки данных часто состоят из так называемых бункеров (silo), когда физическим стойкам с серверами и другими аппаратными компонентами назначается какая-то определенная задача (приложение). Значительная часть производимого трафика (операции, коммуникация между процессами) остается внутри стойки, за ее пределы выходит лишь незначительный объем данных (см. Рисунок 2).

 

Рисунок 2. Традиционная архитектура ЦОД.

 

Традиционная архитектура, подобная представленной на Рисунке 3, обычно реализуется посредством коммутаторов уровня доступа (Access Layer Switch), установленных в верхней части стоек (архитектура Top of Rack, ToR). С помощью нескольких портов для каскадирования (Uplink Port) они соединяются с уровнем распределения (Distribution Layer) или уровнем ядра (Core Layer). Нередко такая архитектура потребляет чрезмерные ресурсы. Во многих случаях отдельным бункерам (стойкам) выделяются собственные подсети IP, а нижележащий уровень распределения производит маршрутизацию уровней L3/L4.

 

Рисунок 3. Традиционный трехступенчатый дизайн сети.

 

В традиционных средах оснащение магистральных и распределительных коммутаторов позволяет им выполнять много сложных сетевых задач (обработка объемных таблиц маршрутизации и адресов, пакетный анализ, шифрование и т. д.). Поэтому в подобных коммутаторах удельная стоимость одного порта и потребляемая ими мощность выше, чем в устройствах, ориентированных исключительно на второй уровень. Магистральные коммутаторы отвечают преимущественно за трафик в «северном» направлении (от клиента к другой сети или в Интернет), где коммуникация между процессами и подключение систем хранения встречается реже. Такие критерии, как сокращение задержек, предотвращение избыточных резервов или точно прогнозируемое качество передачи, здесь менее важны.

Для сред Ethernet характерен высокий уровень избыточного резервирования (от 5:1 до 10:1) между сервером и портами для каскадирования, особенно в случае использования дешевых коммутаторов доступа. Набирающая обороты виртуализация, дополненная мобильностью виртуальных систем, порождает все больше трафика в направлении «восток – запад» между серверными стойками, а также между серверами и подсистемами хранения. Из этого следует вывод: агрегирующие коммутаторы с избыточным запасом портов для каскадирования уже неприемлемы.

 

МАСШТАБИРОВАНИЕ СЕТЕЙ В ЦОД

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

 

Рисунок 4. Следствия ограниченной масштабируемости Ethernet.

 

Изменения, происходящие в ЦОД, предполагают снижение уровня избыточности, а также переход со стандарта 1 GbE к 10 GbE, что — при условии сохранения в ЦОД прежней иерархической древовидной структуры — привело бы к стремительному увеличению расходов. До недавнего времени проблемы затрат и масштабируемости решались с помощью достаточно высокой степени избыточности между различными уровнями (уровни распределения и ядра). К примеру, к 48-портовому коммутатору с четырьмя портами для каскадирования может подключаться от 32 до 36 серверов. Магистральный коммутатор в полном оснащении имеет 256 портов и, таким образом, позволяет обслуживать около 2 тыс. серверов. Дальнейшее расширение обеспечивается созданием еще одного иерархического уровня (см. Рисунок 5).

 

Рисунок 5. Иерархическая древовидная структура Ethernet.

 

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

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

В отличие от Ethernet, коммутирующие модули стандартов Infiniband и Fibre Channel позволяют использовать множественные пути между двумя конечными точками. Обычно специальное управляющее ПО Fabric Manager обеспечивает оптимальное использование всех портов. Множественные пути используются параллельно, поэтому доступная пропускная способность линейно возрастает вместе с количеством параллельных соединений. Возможны даже топологии с ячеистой структурой. Чтобы подобное поведение стало возможным и для Ethernet, комитеты IEEE и IETF уже занимаются расширением стандарта Ethernet, однако пройдет еще несколько лет, прежде чем удастся разработать и распространить единый стандарт для всех производителей.

 

ВЕРТИКАЛЬНОЕ И ГОРИЗОНТАЛЬНОЕ МАСШТАБИРОВАНИЕ

Для наделения ЦОД большей мощностью существует два возможных подхода: масштабирование вертикальное (Scale-up), когда используется более мощная монолитная система, и горизонтальное (Scale-out), когда несколько небольших машин объединяются в один логический кластер.

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

 

CONVERGED ENCHANCED ETHERNET

Стандарт Infiniband (частично и Fibre Channel) разрабатывался в расчете на горизонтальное масштабирование. Целью было создание максимально простой коммутационной инфраструктуры с поддержкой ячеистых топологий и множественных путей, а также с централизованным управлением обнаружением устройств (Discovery) и правилами для них (Policy).

На протяжении последних нескольких лет комитет IEEE работает над тем, чтобы дополнить стандарт Ethernet функционалом, аналогичным возможностям Infiniband, и сформировать таким образом новый стандарт Converged Enhanced Ethernet (CEE), который позволил бы использовать Ethernet как единую технологию для горизонтально масштабируемых центров обработки данных.

Производители, имеющие многолетний опыт в мире технологий Infiniband (например, Voltaire), уже сегодня предлагают решения для Ethernet, поддерживающие произвольное горизонтальное масштабирование без потери производительности и без линейного возрастания затрат. Коммутаторы Infiniband и 10 Gigabit Ethernet, выпускаемые компанией Voltaire, администрируются с помощью центрального ПО Fabric Manager, а также поддерживают миграцию ЦОД следующего поколения к виртуализированным и автоматизированным сервис-центрам.

Ханс Блей — менеджер по продажам и маркетингу в компании Atlantik Systeme.