Какой должна быть сетевая фабрика ЦОДа

Сетевое оборудование выбирается исходя из планируемых нагрузок и архитектуры сети, в которой оно будет работать. Для современной корпоративной сети нагрузку составляют преимущественно небольшие потоки трафика от пользователей, и направлены они «с юга на север», т.е. от коммутаторов доступа к пограничным маршрутизаторам (рис. 1).

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

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

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

На требования к сети ЦОДа помимо архитектуры приложений сильно влияет их виртуализация. Одиночное приложение, не связанное с хранением данных, редко может создать нагрузку на сеть больше 1 Гбит/c, но десятки приложений – запросто. Виртуализированные же приложения могут размещаться на серверах крайне плотно и должны быстро между ними перемещаться, значит, широкая полоса пропускания необходима везде (рис. 3).

Ключевые устройства в сети ЦОДа – это коммутаторы, которые являются самым эффективным по стоимости за 1 Гбит/с сетевым компонентом, способным обеспечить нужную производительность.

Потоки трафика, которые не покинут сеть ЦОДа и не требуют инспекции с помощью ИБ-оборудования, обычно обрабатываются исключительно коммутаторами. Группу коммутаторов, которые доставляют такой трафик в пределах одного ЦОДа, обычно выделяют в отдельную логическую единицу и называют ее сетевой фабрикой (рис. 4).

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

В ЦОДе же такое недопустимо. Если доступ к сети потеряет даже один сервер, то это может причинить ущерб вплоть до остановки бизнес-процессов целой компании – все зависит от критичности приложений, которые на этом сервере размещены. Поэтому в сети ЦОДа резервируется всё, начиная с подключения конечных устройств, коммутаторов и до подключения ЦОДа к внешним сетям (рис. 5).

Архитектура сетевой фабрики воплощает простой принцип – максимально быстрая и резервированная связь между любыми двумя коммутаторами. Он реализуется в сети Клоза. В ней коммутаторы могут играть всего две роли: «листьев» (Leaf), к которым подключаются серверы и внешние сети, и «ствола» (Spine), который обеспечивает взаимодействие «листьев» (рис. 6).

Использование такой архитектуры в ЦОДе дает ряд преимуществ по сравнению с классической двухуровневой архитектурой со «свернутым» ядром сети (collapsed core):

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

Если фабрику предполагается использовать как транспорт для СХД, то стоит обратить внимание на коммутаторы с глубоким буфером. Многие протоколы доставки данных критически реагируют на потерю пакетов – либо останавливают передачу данных, либо существенно ее замедляют. При этом в ряде случаев увеличение скоростей на эту ситуацию не повлияет. Скажем, когда одна из сторон данные отправляет, а другая принять их не готова (например, перегружена запросами). Глубокий буфер (у некоторых производителей его размер достигает 1 Гбайт) позволяет коммутаторам буферизовать такие «лишние» данные и при наличии у серверов/СХД механизмов управления скоростью передачи данных практически полностью избежать потерь пакетов (рис. 7).

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

Довольно популярный и широко поддерживаемый производителями вариант – VXLAN (Virtual Extensible LAN) в сочетании с EVPN (Ethernet Virtual Private Network). VXLAN туннелирует трафик второго уровня в пакеты UDP, а EVPN контролирует процессы построения VXLAN-туннелей и распространения информации о MAC-адресах между коммутаторами. Ключевая особенность использования информации о MAC в EVPN заключается в том, что такой адрес привязывается не к физическому порту, а к IP-адресу коммутатора, на котором этот MAC находится. 

Если планируется использовать стороннюю, полностью программную систему виртуализации сети, то полноценная поддержка VXLAN EVPN на коммутаторах обычно не требуется, они предоставляют системе виртуализации простую L3-связность. В таком случае может быть достаточно поддержки на коммутаторе простого VXLAN-туннелирования в сочетании с протоколом OVSDB (Open vSwitch Database Management Protocol). OVSDB позволяет частично отдать коммутатор под управление контроллеру системы виртуализации сети для того, чтобы он мог распространить действие политик виртуальной сети на физические серверы, а VXLAN дает возможность эту виртуальную сеть «дотянуть» до них.

Если от фабрики требуется нетиповой функционал, не реализованный ни одним из вендоров, к примеру, сложная балансировка трафика или его маршрутизация/коммутация/фильтрация на основе нестандартных признаков, то хорошим выбором может стать использование коммутаторов с программируемыми ASIC. Они позволяют описать логику обработки трафика на специальном языке программирования, после чего коммутатор сможет выполнять ее практически со скоростью сетевых интерфейсов. К сожалению, на данный момент при работе в таком режиме коммутаторы требуют заново описать и всю стандартную логику (включая классические протоколы маршрутизации), но производители работают над выпуском «комбинированных» устройств.

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>