Техническая реализация модуля на 24 десятки для MLXe

Недавно анонсированный Brocade модуль на 24 порта 10Gbe в трое увеличил максимальную плотность портов в шасси MLXe. Суммарно в одном маршрутизаторе теперь можно установить до 768 десяти гигабитных портов с поддержкой MPLS и OpenFlow.
В модуле используется новый ASIC MaxScale-160 имеющий пропускную способность 160 гигабит и имеет 8 интегрированных портов 10 GbE. В новом модуле установлено 3 таких ASIC-а что дает в сумме 24 десятки без переподписки.
В каждый ASIC интегрировано 33 различных компонента, включая пакетные процессоры, FPGA, ACL TCAM, packet lookup SRAM и интерфейсные порты.
На фото можно увидеть разницу между старым 8-портовым модулем (2010 год выпуска) и новой моделью 2012 года. Не смотря на увеличение числа портов, новый модуль имеет на много меньшее количество активных компонентов, что увеличивает время наработки на отказ (MTBF) и снижает энергопотребление.


Процессор используемый в ASIC MaxScale-160 состоит из 1.38 млн транзисторов и выполнен по 45-нанометровой технологии. Он имеет 352 Мбита встроенной памяти . Новый модуль самый "зеленый" из всех новейших разработок Brocade. Он потребляет всего 13.3 Ватта на порт. Для сравнения модуль предыдущего поколения съедает 30.75Ватт на порт, а потребление в старых модулях XFP-формата доходило до 75 Ватт на порт.

Следующая версия ASIC-а, которая сейчас в разработке - MaxScale-400 будет иметь 400 гигабит пропускной способности, и интегрирует в себе 2 миллиона транзисторов выполненных по 32 нанометровой технологии. 

Контроллеры доставки приложений (ADC) - новое прочтение

Балансировка нагрузки

Контроллеры доставки приложений (Application Delivery Controllers) или балансировщики нагрузки стали обязательным пунктом в задачах связанных с построением ЦОД. Редкий проект обходится без использования этих устройств, но не всегда заказчики ясно понимают для чего им нужны балансировщики и как сделать правильный выбор. Ранее я приводил критерии выбора балансировщиков нагрузки, Гартнер тоже не остается в стороне и выпустил очередной отчет на эту тему, в котором на "ста пятидесяти" листах доходчиво объясняет разницу одних и других. Можно легко потеряться в объеме информации которые вендоры вываливают на заказчика пытаясь превзойти друг друга по поддерживаемым фичам и параметрам производительности. Недавно мне попалась интересная статья, которую вы можете прочитать в оригинале, где Joshua Bixby президент компании Strangeloop, занимающейся веб-оптимизацией приводит результаты их тестов контроллеров ADC и их пользы относительно того или иного функционала.
Не буду приводить все выкладки, но в целом получается что многие задачи которые заявлены производителями как достоинства ADC-контроллеров, на самом деле с тем же успехом выполнятся самими серверами и выгоды от использования контроллеров для улучшения сервиса в сторону клиентов по некоторым параметрам - ноль.
Это касается следующих задач:

1. Кэширование - не будьте наивными, мощный сервер сделает это лучше и быстрее балансировщика, с его ограниченным и занятым на другие задачи ресурсом. По большому счету "кэширование" вообще не задача балансировщика нагрузки и эту фичу анонсируют только производители ADC базирующихся на традиционной серверной архитектуре, где в основе сидит юниксовое ядро и есть диски куда можно за одним скидывать кэш. В общем это те устройства где кэширование является бесплатным дополнением к ОС, а раз есть почему бы не использовать...
2. Компрессия - ну не справляется одно устройство с тем что должна делать серверная ферма, тем более когда алгоритмы компрессии уже встроены в протокол HTTP. Комрессия на ADC это пережиток прошлого, когда под эту задачу всегда нужно было ставить специализированные устройства.
3. TCP multiplexing - результаты тестирования с отключенным и запущенным функционалом не показали разницы в задержках оклика на запросы. Этот функционал может потребоваться только в случае возникновения взрывных нагрузок на ферму серверов. В нормальной жизни мультиплексирование не дает какого либо ощутимого эффекта.

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

Шлюз VXLAN в Brocade ADX

Компания Brocade анонсировала разработку VXLAN-шлюза на базе контроллеров приложений ServerIron ADX. Новый функционал позволит усилить интеграцию решений Brocade с VMware с целью построения распределенных облачных центров обработки данных, позволяющих виртуальным машинам свободно мигрировать между локальными дата-центрами.

VXLAN это своего рода расширение традиционных VLAN, ограниченных по масштабированию 4 тысячами инстансов. VXLAN увеличивает число подсетей до 16 миллионов, что позволяет использовать устройства обладающие таким функционалом в сетях операторов и крупных предприятий. Подробнее про VXLAN  можно прочитать в по ссылке: http://www.vmgu.ru/news/vmware-vxlan-for-vsphere

Data Center Fabric Checklist: 8 индикаторов для выбора Ethernet фабрики

Термин "фабрика" одно из самых популярных в последнее время маркетинговых слов в области сетевой индустрии. Новая концепция построения сети стратегически важна для организаций которым требуется максимальная отдача от виртуализации в их дата-центрах. Множество вендоров, таких как Brocade, Cisco, Juniper, Extreme, Alcatel-Lucent, Avaya, Extreme и Enterasys, предлагают видение ЦОД-фабрики базирующейся на сети передачи данных, однако некоторые, например Xsigo говорят о фабрике базирующейся на серверах. Так или иначе, очевидно что архитектура дата-центров меняется. Вопрос, в каких случаях компания должна рассматривать внедрение фабрики в своем ЦОД-е? Вот восемь факторов которые стоит принимать во внимание:

1. Проблемы производительности в существующей сети. Если сетевые или серверные линки перегружены и являются узким местом сети, нужно думать об апгрейде и переход к фабрике позволит получить запас прочности на годы вперед.
2. Мобильность виртуальных машин (VM). Виртуализация - один из драйверов подтолкнувших к созданию фабрики. Если виртуальные машины должны мигрировать в еределах стойки, можно оставить старую архитектуру. Если требуется миграция между стойками - фабрика оптимальный механизм для обеспечения прозрачной миграции за счет плоской структуры с множеством горизонтальных связей.
3. Ограничения инфраструктуры. Есть или возможне недостаток мощностей, охлаждения, рэкового пространства. - Фабрика позволит увеличить плотность подключения серверов и виртуальных машин, уменьшить общее число серверов за счет повышения эффективности их использования. Конвергенция снизит энергопотребление и общее число устройств необходимых для построения сети
4. Конвергенция. Объединение SAN и LAN сетей в единую инфраструктуру требует внедрения фабрики, так как традиционная архитектура не приспособлена для передачи FCoE трафика.
5. Модернизация сети стоит в ближайших планах. Есть необходимость в переходе на 10, 40 а может и 100 гигабитные линки и нужно потратить деньги с умом. - Переход на фабрику позволит получить максимальную отдачу от вложений и снизит стоимость внедрения и общую стоимость владения инфраструктурой.
6. Консолидация или строительство нового дата-центра. Любой новый ЦОД должен использовать все преимущества новой архитектуры на базе фабрики. Внедрение старых сетевых технологий ограничивает срок жизни и эффективность центра обработки данных в современных условиях. В новый ЦОД ставятся новые сервера, новые системы хранения и сеть тоже должна быть новой.
7. Более 50% ваших приложений уже виртуализованы. Надежность сети становится крайне важным фактором для обеспечения доступности сервисов и ресурсов. Фабрика позволит обеспечить большую надежность и производительность по сравнению с традиционной архитектурой.
8. Есть проблемы с содержанием и сопровождением существующей сети. Устаревшая архитектура сложна и дорога в обслуживании. - Фабрика проще в использовании и это краеугольный камень современного дизайна. Если содержание  сети становится все более обременительным, возможно пришло время переключаться на фабрику.

Фабрика это решение всех перечисленных выше проблем. Если вы столкнулись с одной из них, подумайте о смене сетевой архитектуры в сторону Ethernet-фабрики. Погрузитесь в детали и почувствуйте разницу!


По материалам статьи Zeus Kerravala

MCT скоро и на BigIron RX

По информации от продакта Brocade по линейке BigIron Manoj Asnani, скоро в эти коммутаторы будет добавлен функционал Multi-Chassis Trunking (MCT).
MCT жизненно необходим в центрах обработки данных для обеспечения отказоустойчивости решения и уменьшения времени сходимости при сбоях.  Год назад этот функционал появился в маршрутизаторах NetIron, затем был анонсирован для FastIron SX (начиная с прошивки 7.4), и наконец появится и в флагманских устройствах Brocade для сетей Enterprise и ЦОД-ов - коммутатрах BigIron RX.

MCT позволяет двум шасси работать вместе как одно устройство и обеспечивать подключение к этому виртуальному коммутатору по нескольким аггрегированным линкам без использования протокола STP. Это дает возможность использовать всю доступную пропускную способность сети, обеспечивает отказоустойчивость и упрощает дизайн сети.




Добавление MCT возможно простым апгрейдом софта и не требует какого-либо специального лицензирования или апгрейда железа. При объединении двух шасси RX-16 суммарная пропускная способность такой системы будет более 3 террабит в секунду.
Ожидаемый срок добавления MCT в RX - 2 квартал 2012 года.