Выступая на форуме «МИР ЦОД. Инфраструктура», Александр Скороходов, инженер-консультант Cisco, выделил четыре тенденции, которые оказывают наибольшее влияние на изменение требований к сетям ЦОДов. Это популярность облачной модели, увеличение числа проектов в области Больших Данных, рост интереса к использованию микросервисной архитектуры приложений, а также к гиперконвергентным решениям.

На один физический сервер приходится все более высокая нагрузка, что приводит к росту нагрузки и на сеть. «15 лет назад один физический сервер, как правило, обслуживал только одно приложение, 5 лет назад — уже 15–20 виртуальных машин, а сегодня он может «нести» до нескольких сотен контейнеров, что позволяет еще более эффективно использовать вычислительные ресурсы», — рассуждает эксперт Cisco.

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

Говоря о возросших требованиях к сети, Борис Нейман, старший системный инженер компании Mellanox, отмечает, что сегодня один сервер способен генерировать до 100 Гбит/c. Огромные объемы трафика передаются в горизонтальном направлении при переезде «тяжелых» виртуальных машин. «Сколько по времени будет переезжать «живая» база данных размером 128 Гбайт по сети 1 Гбит/с или 10 Гбит/с? — задает он вопрос, и сам на него отвечает. — Скорее всего, она никогда не переедет». Дело в том, что поступающие в реальном времени изменения система будет пытаться перекопировать на удаленный сервер, а с учетом трафика, связанного с миграцией БД, по медленной сети это вряд ли удастся.

На форуме «МИР ЦОД. Инфраструктура» актуальные вопросы сетевой инфраструктуры центров обработки данных обсуждали ведущие эксперты отрасли (на фото слева направо): Александр Скороходов (Cisco), Борис Нейман (Mellanox), Евгений Савельев (Ciena), Максим Каминский (Brain4Net) и другие
На форуме «МИР ЦОД. Инфраструктура» актуальные вопросы сетевой инфраструктуры центров обработки данных обсуждали ведущие эксперты отрасли (на фото слева направо): Александр Скороходов (Cisco), Борис Нейман (Mellanox), Евгений Савельев (Ciena), Максим Каминский (Brain4Net) и другие

 

ETHERNET С ХАРАКТЕРИСТИКАМИ INFINIBAND

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

Чтобы ответить на этот вопрос, Борис Нейман предпринял экскурс в историю. Ethernet был разработан более 40 лет назад для того, чтобы соединить несколько компьютеров в одной комнате или в нескольких соседних комнатах. Со временем область применения этой технологии расширялась, она дополнялась новыми возможностями, однако зачастую эти дополнения можно было характеризовать как «заплатка на заплатке». По мнению эксперта Mellanox, развитие Ethernet сдерживалось базовыми ограничениями в протоколе, а также устаревшей концепцией, согласно которой коммутатор — очень умное устройство, которое само должно определять маршруты пересылки трафика.

Большинство недостатков Ethernet было устранено в технологии InfiniBand, появившейся в 1999 году. Был разработан полностью новый стек протоколов, начиная с физического уровня. В технологию были встроены механизмы обработки широковещательного и многоадресного трафика, предотвращения петель и штормов. Сами коммутаторы InfiniBand — это очень простые (а потому очень производительные) устройства, инструкции которым дает внешний контроллер. (По сути, это не что иное, как ранняя реализация принципов модной ныне концепции SDN.) Кроме того, технология InfiniBand позволяла приложению запросить канал до удаленного сервера и получить доступ в память этого сервера (RDMA).

Все эти возможности активно использовались в суперкомпьютерах, для которых и была предназначена InfiniBand в первую очередь. «В крупнейшем суперкомпьютере в мире (NASA) 20 тыс. серверов взаимодействуют по единой сети InfiniBand и способны решать одну задачу параллельно, — рассказывает Борис Нейман. — Я не видел ничего подобного, реализованного с помощью традиционного Ethernet».

Тем не менее в последнее время все больше возможностей InfiniBand переносится в технологию Ethernet, что позволяет ей сегодня претендовать на роль универсального сетевого транспорта в ЦОДе. По крайней мере, как утверждает Борис Нейман, это сделано в новом чипе Spectrum, на котором основаны коммутаторы Mellanox. По его мнению, современные решения Ethernet для ЦОДов должны быть широкополосными (поддерживать скорости 10, 25, 40, 50, 100 Гбит/c), обес-

печивать низкие задержки (1–2 мкс для связи «сервер — сервер» через три коммутатора), поддерживать режимы работы без потери пакетов (см. врезку «Чего остерегаться при построении Ethernet-сети ЦОДа?»), протоколы сетей хранения и RDMA, включая RoCEv2. Кроме того, такие решения должны быть хорошо масштабируемыми, гибко управляемыми и открытыми.

 

Чего остерегаться при построении Ethernet-сети ЦОДа?

Возможные проблемы в сети:

  • Потеря небольших пакетов → проблемы с синхронизацией приложений, подтверждением транзакций и записей на удаленный диск и т. д.
  • Увеличенные задержки на больших пакетах → более долгий процесс записи в СХД (и чтения из нее).
  • Неравномерные задержки → отсутствие предсказуемости в работе приложений.
  • Отсутствие справедливости при обработке (buffering/scheduling) → один клиент получит хорошую услугу, а остальные — плохую.

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

Вывод. Не «пускайте» в свой ЦОД коммутаторы, которые теряют пакеты!

Источник: Mellanox

 

ДА ЕЩЕ И ОТКРЫТЫЙ!

На последней характеристике («открытости») стоит остановиться подробнее. Ясно, что сетевое решение от одного производителя — коммутатор или маршрутизатор с «привязанным» к нему программным обеспечением — сбалансировано и хорошо работает. Но такой подход не лишен недостатков. Среди них Борис Нейман отмечает высокую стоимость, зависимость от одного вендора, длительный цикл разработки новых функций. Ряд инициатив, в том числе предложенная Mellanox инициатива Open Ethernet, предполагают дезагрегацию коммутатора — отделение «железа» от софта и возможность независимого выбора каждого компонента решения: аппаратного обеспечения (коммутатора bare metal или white box), сетевой операционной системы и приложений, реализующих сетевые функции.

«Независимых сетевых ОС становится все больше и больше, — говорит Борис Нейман. — В основном они базируются на Linux, а значит, на коммутаторе можно быстро запустить новое приложение, реализующее нужные функции».

В качестве примера открытой аппаратной платформы представители Mellanox приводят свои коммутаторы на базе новейшей микросхемы ASIC Spectrum. Сама по себе эта микросхема обладает впечатляющими характеристиками: неблокирующая коммутация без потерь пакетов с производительностью 6,4 Тбит/с и задержкой менее 300 нс, что позволяет поддерживать до 32 портов по 100/56/40G или до 64 портов 50/25/10GbE. Соответствие принципам Open Ethernet означает возможность работы с различными сетевыми ОС — как с открытым кодом, так и с коммерческими системами. В ходе форума Open Compute Project (OCP) Summit в марте 2016 года была продемонстрирована работа сети, состоящей из шести коммутаторов на базе Spectrum с шестью разными сетевыми ОС: Cumulus Linux, Mellanox OS, Microsoft ACS (SONiC), HP OpenSwitch, MetaSwitch и BaiduOS.

По мнению Максима Каминского, технического директора компании Brain4Net, применение оборудования bare-metal обеспечивает свободу выбора, модернизации, применения и, как следствие, снижает затраты на инфраструктуру по сравнению с проектами, основанными на традиционных решениях от одного производителя. «Конечно, такие решения отлично отлажены, но они тяжело и/или дорого кастомизируются и модернизируются», — говорит он. Это очень серьезный недостаток в новых условиях, когда необходимо максимально быстро изменять или добавлять сервисы.

СКОРОСТЬ ВЫШЕ, ЦЕНА ТА ЖЕ

Начиная с 2008 года эксперты рекомендуют использовать для подключения серверов в ЦОДе каналы 10 Гбит/c. Как утверждает Александр Скороходов из Cisco, сегодня к такой скорости (для подключения серверов) все уже привыкли, в ближайшей перспективе — подключение на скорости 25 Гбит/c. Для заказчиков очень важно, что благодаря техническому прогрессу в микроэлектронике в 2,5 раза более высокая скорость обеспечивается при той же цене за порт. Решения 25G обратно совместимы с гигабитными и 10-гигабитными системами (одинаковые гнезда для трансиверов 1/10/25G SFP). Кроме того, эти решения можно стыковать с новым поколением систем 100G (с трансиверами QSFP28), в которых 100-гигабитная скорость достигается за счет объединения четырех линий по 25 Гбит/c: при помощи кабелей-разветвителей порт 100GbE можно разделить на четыре канала 25 Гбит/c. (До недавнего времени основная реализация 100GbE была десятиканальной: для получения скорости в 100 Гбит/c объединялись десять каналов по 10G, что делало такой вариант существенно более дорогим.)

Что касается соединений между коммутаторами, то, как утверждает Александр Скороходов, соединения 40 Гбит/c стали в последние годы стандартом даже на довольно консервативном российском рынке. Здесь следующая ступень — 100G. Используемые в системах нового поколения компактные трансиверы QSFP28 обратно совместимы с трансиверами QSFP, применяемыми для систем 40G. При этом производители, по крайней мере Cisco, обещают, что стоимость порта при переходе от 40G к 100G почти не изменится (см. рис. 1).

Рис. 1. Тот же формат, та же цена, а скорости в 2,5 раза выше. Новая модель коммутатора Nexus (внизу) в конфигурации 48 портов 1/10/25G и 6 портов 40/100G предлагается по той же цене, что и модель предыдущего поколения с 48 портами 1/10G и 6 портами 40G
Рис. 1. Тот же формат, та же цена, а скорости в 2,5 раза выше. Новая модель коммутатора Nexus (внизу) в конфигурации 48 портов 1/10/25G и 6 портов 40/100G предлагается по той же цене, что и модель предыдущего поколения с 48 портами 1/10G и 6 портами 40G

 

Помимо повышения требований к производительности, растут и требования к масштабируемости. Это связано не только с общим разрастанием сетей (ростом числа узлов), но и с тем, что на один порт приходится все больше точек взаимодействия (подключений виртуальных машин), увеличивается число подсетей и т. д. Ответом на эти требования становится повышение плотности портов коммутаторов, числа поддерживаемых сетевых адресов/подсетей (MAC, IPv4, IPv6, VXLAN-сегменты...). Кроме того, как отмечает Александр Скороходов, горизонтальное масштабирование производительности обеспечивает переход к архитектуре сетей Клоза с эффективным распределением нагрузки (эта архитектура еще называется Leaf-Spine), а также реализацией дополнительных функций (безопасность, сетевая аналитика, телеметрия...) на скорости канала.

ВИРТУАЛИЗАЦИЯ, КОНТЕЙНЕРЫ И… SDN

Относительно новым требованием к сетевым инфраструктурам стала необходимость поддержки разных видов нагрузки. При общей тенденции к виртуализации почти в любой системе остаются невиртуализированные серверы: например, «унаследованные» системы, системы с вертикальным масштабированием (СУБД), кластеры БД. Наряду с этим активно развивается микросервисная архитектура приложений. «Про эту тенденцию в России говорят меньше, но она способна привести к кардинальным изменениям в прикладных архитектурах, — говорит Александр Скороходов. — Все больше приложений создается в соответствии с микросервисной архитектурой с использованием контейнеров».

В этих условиях сетевая инфраструктура должна «понимать» и эффективно поддерживать разные типы нагрузок, включая невиртуализированные серверы, виртуальные машины и контейнерные приложения. Практически неизбежна разработка новых ИТ-стеков, ориентированных на контейнеры и микросервисы. При этом контейнеризованные приложения смогут работать непосредственно поверх аппаратного уровня без промежуточного уровня в виде гипервизора. Что касается сетевой инфраструктуры, то, как считают в Cisco, ее сетевые решения ACI отлично подходят для сред, где используются контейнеры и микросервисы.

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

 

ACI в UNITEL

SDN-подобная архитектура ACI (Application Centric Infrastructure), несмотря на свою относительную новизну, пользуется популярностью у заказчиков. По данным Cisco, в мире решения ACI применяют уже более 1400 компаний. Одна из них — оператор UNITEL, входящий в состав группы компаний «ВымпелКом», предоставляющий услуги сотовой связи в Узбекистане. Как рассказал Тимур Барабанов, руководитель направления управления сетями и телефонными станциями службы развития ИТ-инфраструктуры UNITEL, задача кардинальной модернизации сети ЦОДа встала в 2014 году в связи с бурным развитием бизнеса компании. Среди недостатков существовавшей на тот момент инфраструктуры, построенной на базе четырех модульных коммутаторов Cisco 6506E, он назвал отсутствие возможности подключения хостов агрегируемыми линками к отдельным шасси, блокировку отдельных портов вследствие работы протокола STP, сложность масштабирования сети, проблемы с разделением ресурсов сети на уровне отдельных сервисов. Новое решение должно было устранить эти недостатки, а также обеспечить переход с интерфейсов 1 Гбит/с на 10 Гбит/с на уровне подключения серверов и повысить отказоустойчивость за счет применения новых технологий высокой доступности.

Вместо модернизации коммутаторов серии 65xx было решено использовать новую архитектуру ACI на базе устройств Cisco Nexus 9K. Как оказалось, такое решение позволило не только эффективно выполнить поставленные задачи, но и сэкономить средства: переход на платформу Cisco Nexus обошелся более чем в два раза дешевле модернизации существующих Cisco 6500 (в первую очередь за счет существенно более низкой стоимости порта 10G).

Сеть ЦОДа UNITEL, построенная на базе архитектуры Cisco ACI
Сеть ЦОДа UNITEL, построенная на базе архитектуры Cisco ACI

 

Новая инфраструктура построена по топологии spine-leaf: на уровне «ствола» (spine) установлены коммутаторы Nexus 9336PQ, а в качестве «листьев» (leaf) — Nexus 9396PX (связь между коммутаторами «ствола» и «листьями» организована по каналам 40G на основе многомодовой оптики). Кроме того, для подключения большей части серверов задействованы так называемые выносы FEX: Nexus 2248TP-E и Nexus 2232PP. Установка коммутаторов Top of Rack в стойки с активным оборудованием позволила сократить расходы на кабельную инфраструктуру. Установленный контроллер Cisco APIC представляет собой кластер из серверов Cisco UCS — APIC Appliance.

В новой инфраструктуре, реализованной по принципу сетевой фабрики, протокол STP не используется, и, таким образом, связанные с ним проблемы не возникают. Тимур Барабанов особо отмечает возможность разделения ресурсов сети на уровне сервисов, что обеспечивает более высокую безопасность, а также широкие возможности интеграции с различными службами VMware, F5 и др. Наряду с повышением производительности и масштабируемости, новая сеть позволяет гарантировать высокий уровень доступности для различных приложений, баз данных и других сервисов.

 

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

СЕТЬ МЕЖДУ ЦОДАМИ

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

Как указывает эксперт Ciena, в настоящее время для взаимодействия между ЦОДами используют три основных варианта (см. таблицу). Первый вариант — через обычный Интернет. При низкой стоимости в этом случае заказчик получит также низкий уровень безопасности и производительности. Второй вариант — сервис IP VPN, предлагаемый многими операторами. Этот сервис достаточно защищен и доступен по цене, к тому же можно заказать необходимую производительность. Но, по мнению Евгения Савельева, он не всегда выгоден операторам, поэтому многие из них вместо IP VPN стараются предлагать услугу L2 VPN, которая для них экономически более привлекательна. Третий вариант — выделенные каналы, как чисто оптические, так и оптические с агрегацией пакетов. Для таких подключений характерны очень высокие безопасность (особенно в случае с DWDM) и производительность, стоимость же их постепенно снижается.

Различные варианты для организации связи между ЦОДами
Различные варианты для организации связи между ЦОДами

 

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

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

В целом в облачном мире сеть все чаще воспринимается как набор ресурсов, доступ к которым осуществляется через удобные системы управления. Причем это не только канальные ресурсы, но и различные сетевые сервисы, реализуемые на базе тех же ЦОДов по модели NFV. Как отмечает Евгений Савельев, vCDN, vRouter, vFirewall и другие виртуальные сервисы работают на недорогих и распространенных серверах с виртуальными машинами. Модель NFV позволяет оператору гораздо быстрее разрабатывать, внедрять и подключать новые типы услуг и новых пользователей. При этом именно ЦОД становится наиболее важным ресурсом сети, поэтому неудивительно стремление многих операторов преобразовать свои традиционные узлы связи в ЦОДы, чтобы на их базе предоставлять виртуальные сетевые функции. Этот процесс получил в телекоммуникационной отрасли название CORD — Central Office Re-architected as a Datacenter.

В распределенной среде, охватывающей различные виды ЦОДов, традиционные сети, инфраструктуры SDN, а также набор сервисов NFV, критически важное значение приобретают системы управления и оркестрации. Компания Ciena в качестве такой платформы предлагает платформу оркестрации Blue Planet Software Suite, реализованную на архитектуре микросервисов. В основе этой платформы — мультидоменный оркестратор, который способен взаимодействовать с различными SDN-контроллерами, в том числе наиболее известных производителей. В состав Blue Planet Software Suite входит ONOS — сетевая ОС для SDN, основанная на открытом ПО. ONOS ориентирована на несколько важных областей применения, одна из которых — уже упомянутое преобразование традиционных узлов связи в ЦОДы (CORD). Как отмечают представители Ciena, Blue Planet ONOS обеспечивает открытую, высокопроизводительную операционную систему SDN для управления инфраструктурой на базе устройств white box.

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

Александр Барсков, ведущий редактор «Журнала сетевых решений/LAN».