Современные сети Ethernet давно уже стали неотъемлемой частью нашей жизни, а уж бизнес-процессы без них и вовсе немыслимы. И их пропускная способность является той характеристикой, рост которой крайне востребован. Скорость 1 Гбит/с давно уже стала настолько расхожей, что ее предоставляют даже провайдеры частным лицам. Но как только дело касается передачи сколько-нибудь серьезных потоков информации этого уже явно недостаточно, и можно сказать, что повсеместным стандартом сейчас является 10G, причем с разъемами не Base-T, а SFP+, позволяющими использовать как медные патчкорды на дальностях до 7 метров (стойка или группа стоек), так и оптические линии связи. Ну а для высоконагруженных линий передачи данных (уровни агрегации, интерконнект кластера для высокопроизводительных вычислений, подключения мощных СХД) используется 40G QSFP+, представляющий собой объединение четырех линий 10G SFP+.
Но производительность серверов растет, потоки данных тоже, нагрузка на сеть становится все выше, а значит уже давно назрела необходимость в переходе на большие скорости. Достаточно давно существуют 100G продукты в форматах CFP, CFP2, CFP4, но они неадекватно дороги для применения в серверной инфраструктуре и необходимо было создание приемлемого по стоимости продукта. Для этого был создан 25G Consortium, который вместе с Ethernet Alliance занялся разработкой нового промышленного стандарта, призванного поднять скорости в типовых сетях в 2,5 раза. Там где заканчивается разработка стандарта, в дело вступает 2550100 Alliance, созданный для продвижения продуктов в массы. Об итогах их работы и степени готовности стандарта к массовому нашествию на рынок мы сейчас и поговорим.
Итак, к нам приходит новый стандарт. Базовой скоростью в нем будет 25 ГБит/с, объединение двух линий дает 50 ГБит/с, а четырёх — 100 ГБит/с.
Начнем с того, что новый стандарт является эволюционным, а не революционным развитием. С точки зрения работы с сетью все схемы работы, протоколы, технологии и рекомендации остаются прежними, меняется только физический уровень. Все основы для этого заложены уже давно: стандарт описан в IEEE Std 802.3ba-2010, а с 2011 года выпускается соответствующее ему оборудование, правда, в виде магистральных маршрутизаторов, соответствующих карт и трансиверов. 4 года назад это был самый пик технологий и стоили они очень существенных денег, сейчас же речь идет о создании общеупотребительного оборудования для ЦОД в виде многопортовых стоечных коммутаторов с низким энергопотреблением, сетевых адаптеров и соответствующих кабелей. С точки зрения разъемов нам предстоит замена SFP+ на SFP28 и, соответственно, QSFP+ на QSFP28.
Любопытно, что разъемы SFP28 и QSFP28 мало чем отличаются от привычных уже SFP+ и QSFP+, чем выгодно отличаются от решений в формате CFP, использовавшихся в магистральном оборудовании. Соответствующим образом обстоит ситуация и с энергопотреблением — лазеры нового поколения обеспечивают менее 3,5 Вт энерговыделения на 100G порт, что и позволяет создавать компактные, пригодные для массового использования решения.
С точки зрения обратной совместимости все в порядке — все появляющееся оборудование на текущий момент поддерживают работу на скоростях 10/40G, поэтому миграцию на новый стандарт можно осуществлять постепенно, добавляя к старому 10/40G оборудованию новые 25/100G коммутаторы и плавно подтягивая скорость до нового стандарта на необходимых участках сети.
Что касается готовности нового стандарта к массовому производству и внедрению, то здесь, на наш взгляд, все обстоит достаточно неплохо. Уже сейчас существует реализованный в железе, текстолите и кремнии полный спектр необходимого оборудования, например:
— коммутаторы
— сетевые карты
-трансиверы
— кабели
— оборудование для тестирования линий
Соответственно, все в порядке и широкой поддержкой стандарта со стороны производителей компонент: свои продукты уже представили такие гранды, как Qlogic, Avago,Cavium, Finisar, Broadcom, Ixia, Mellanox. А общий список компаний, поддержавших новых стандарт настолько велик, что проще дать ссылку, чем приводить здесь весь список. Правда, не можем ехидно не заметить, что если мы уже присоединились к этому списку (о нашем продукте чуть позже), то вот такая незначительная компания как Intel — нет.
Кроме шуток, в это несколько трудно поверить, но такое ощущение, что Intel полностью упустила появление 25/100G, сосредоточившись на доводке своего решения X710. Ну что ж, конкуренты явно не замедлять отъесть кусок рынка, массово выпустив свои сетевые адаптеры.
А еще довольно любопытно будет посмотреть на то, с какой скоростью ведущие производители сетевого оборудования начнут переходить на новый стандарт и какими аргументами будут выделять свое решение на merhant silicon на фоне конкурентов — ведь в ближайшее время все будет строиться вокруг одной и той же матрицы Broadcom Tomahawk.
Еще одним немаловажным фактом, который обещает сильно работать на популярность нового стандарта является то, что его стоимость не будет радикально отличаться от текущих 10/40G решений. Обычно нововведения (или инновации, для тех, кому так привычнее) довольно долго отпугивают от себя несоразмерно высокими ценами, в результате чего пионерами их внедрения становятся только те, кто уже не может жить без перехода на самые производительные технологии. В этот же раз упор планируется именно на массовость решения, поэтому даже с учетом «наценки за новизну» (а совсем от нее избавиться невозможно) новые решения по соотношению цена-производительность обещают уже на старте превосходить своих предшественников.
Кому нужны сетевая инфраструктура со столь высокой пропускной способностью? Ну давайте рассмотрим очевидные примеры внедрения.
Использование в Web-Scale инсталляциях
Если рассматривать типичные широкомасштабные инсталляции в виде стоек, полностью забитых серверами (40U, 80 узлов по 1/2U), то 2-портовые 10G адаптеры в каждом узле заменяются на аналогичные 25G адаптеры. Соответственно, на TOR-уровне 4 10G коммутатора, например Eos420 (48 портов 10G, 6 портов 40G) можно заменить на 2 100G коммутатора, в которых из 32 100G портов 20 с помощью break-out кабелей обеспечивают соединение с узлами по 25G, а оставшиеся 12 работают на аплинк.
Достоинства такого решения:
Использование в высокопроизводительных вычислениях
В HPC в настоящее время чаще всего используется 56G InfiniBand. Соответственно, его можно «в лоб» заменить на 100G соединения в рамках блока из 32 серверов.
Достоинства:
Использование для подключения СХД
Уже сейчас блочный или файловый доступ в СХД через Ethernet оказывается практичнее FiberChannel и вплотную подобрался по производительности к InfiniBand. Новый же интерфейс еще более усугубит эту ситуацию, фактически сделав все остальные интерфейсы ненужными.
Достоинства:
Ну и наконец о нашем участии в 2550100.
Со своей стороны мы представили коммутатор Eos 720 с 32 QSFP28 портами. Эта модель стала продолжением нашего имеющегося семейства коммутаторов Eos, и создана в рамках любимой нами идеологии BareMetal Switch, то есть обладает установочной средой ONIE, поддерживающей установку различных сетевых ОС. Коммутатор уже полностью готов и в ближайшее время будет доступен в нашей лаборатории, что же касается поддержки со стороны ОС, то мы сейчас плотно сотрудничаем с их производителями по вопросам совместимости.
Основные характеристики у коммутатора таковы:
Так что подводя итоги можно сказать, что новый стандарт уже полностью готов к приходу на рынок и в течение года стоит ожидать массового появления коммерческих продуктов. Так что планировать свою инфраструктуру стоит уже сейчас.
Но производительность серверов растет, потоки данных тоже, нагрузка на сеть становится все выше, а значит уже давно назрела необходимость в переходе на большие скорости. Достаточно давно существуют 100G продукты в форматах CFP, CFP2, CFP4, но они неадекватно дороги для применения в серверной инфраструктуре и необходимо было создание приемлемого по стоимости продукта. Для этого был создан 25G Consortium, который вместе с Ethernet Alliance занялся разработкой нового промышленного стандарта, призванного поднять скорости в типовых сетях в 2,5 раза. Там где заканчивается разработка стандарта, в дело вступает 2550100 Alliance, созданный для продвижения продуктов в массы. Об итогах их работы и степени готовности стандарта к массовому нашествию на рынок мы сейчас и поговорим.
Итак, к нам приходит новый стандарт. Базовой скоростью в нем будет 25 ГБит/с, объединение двух линий дает 50 ГБит/с, а четырёх — 100 ГБит/с.
Начнем с того, что новый стандарт является эволюционным, а не революционным развитием. С точки зрения работы с сетью все схемы работы, протоколы, технологии и рекомендации остаются прежними, меняется только физический уровень. Все основы для этого заложены уже давно: стандарт описан в IEEE Std 802.3ba-2010, а с 2011 года выпускается соответствующее ему оборудование, правда, в виде магистральных маршрутизаторов, соответствующих карт и трансиверов. 4 года назад это был самый пик технологий и стоили они очень существенных денег, сейчас же речь идет о создании общеупотребительного оборудования для ЦОД в виде многопортовых стоечных коммутаторов с низким энергопотреблением, сетевых адаптеров и соответствующих кабелей. С точки зрения разъемов нам предстоит замена SFP+ на SFP28 и, соответственно, QSFP+ на QSFP28.
Любопытно, что разъемы SFP28 и QSFP28 мало чем отличаются от привычных уже SFP+ и QSFP+, чем выгодно отличаются от решений в формате CFP, использовавшихся в магистральном оборудовании. Соответствующим образом обстоит ситуация и с энергопотреблением — лазеры нового поколения обеспечивают менее 3,5 Вт энерговыделения на 100G порт, что и позволяет создавать компактные, пригодные для массового использования решения.
С точки зрения обратной совместимости все в порядке — все появляющееся оборудование на текущий момент поддерживают работу на скоростях 10/40G, поэтому миграцию на новый стандарт можно осуществлять постепенно, добавляя к старому 10/40G оборудованию новые 25/100G коммутаторы и плавно подтягивая скорость до нового стандарта на необходимых участках сети.
Что касается готовности нового стандарта к массовому производству и внедрению, то здесь, на наш взгляд, все обстоит достаточно неплохо. Уже сейчас существует реализованный в железе, текстолите и кремнии полный спектр необходимого оборудования, например:
— коммутаторы
— сетевые карты
-трансиверы
— кабели
— оборудование для тестирования линий
Соответственно, все в порядке и широкой поддержкой стандарта со стороны производителей компонент: свои продукты уже представили такие гранды, как Qlogic, Avago,Cavium, Finisar, Broadcom, Ixia, Mellanox. А общий список компаний, поддержавших новых стандарт настолько велик, что проще дать ссылку, чем приводить здесь весь список. Правда, не можем ехидно не заметить, что если мы уже присоединились к этому списку (о нашем продукте чуть позже), то вот такая незначительная компания как Intel — нет.
Кроме шуток, в это несколько трудно поверить, но такое ощущение, что Intel полностью упустила появление 25/100G, сосредоточившись на доводке своего решения X710. Ну что ж, конкуренты явно не замедлять отъесть кусок рынка, массово выпустив свои сетевые адаптеры.
А еще довольно любопытно будет посмотреть на то, с какой скоростью ведущие производители сетевого оборудования начнут переходить на новый стандарт и какими аргументами будут выделять свое решение на merhant silicon на фоне конкурентов — ведь в ближайшее время все будет строиться вокруг одной и той же матрицы Broadcom Tomahawk.
Еще одним немаловажным фактом, который обещает сильно работать на популярность нового стандарта является то, что его стоимость не будет радикально отличаться от текущих 10/40G решений. Обычно нововведения (или инновации, для тех, кому так привычнее) довольно долго отпугивают от себя несоразмерно высокими ценами, в результате чего пионерами их внедрения становятся только те, кто уже не может жить без перехода на самые производительные технологии. В этот же раз упор планируется именно на массовость решения, поэтому даже с учетом «наценки за новизну» (а совсем от нее избавиться невозможно) новые решения по соотношению цена-производительность обещают уже на старте превосходить своих предшественников.
Кому нужны сетевая инфраструктура со столь высокой пропускной способностью? Ну давайте рассмотрим очевидные примеры внедрения.
Использование в Web-Scale инсталляциях
Если рассматривать типичные широкомасштабные инсталляции в виде стоек, полностью забитых серверами (40U, 80 узлов по 1/2U), то 2-портовые 10G адаптеры в каждом узле заменяются на аналогичные 25G адаптеры. Соответственно, на TOR-уровне 4 10G коммутатора, например Eos420 (48 портов 10G, 6 портов 40G) можно заменить на 2 100G коммутатора, в которых из 32 100G портов 20 с помощью break-out кабелей обеспечивают соединение с узлами по 25G, а оставшиеся 12 работают на аплинк.
Достоинства такого решения:
- На 150 % выше пропускная способность
- Требуется в 2 раза меньше сетевой инфраструктуры (коммутаторы, кабели) в стойке -> ниже CAPEX
- В 2 раза меньше TOR-коммутаторов -> ниже OPEX
- Поддерживаются все существующие технологии виртуализации и оверлейных сетей (VXLAN, NVGRE, SPB etc)
Использование в высокопроизводительных вычислениях
В HPC в настоящее время чаще всего используется 56G InfiniBand. Соответственно, его можно «в лоб» заменить на 100G соединения в рамках блока из 32 серверов.
Достоинства:
- На 78 % выше пропускная способность
- Ниже CAPEX
- Простое масштабирование системы
- Единая сеть для всех видов трафика
Использование для подключения СХД
Уже сейчас блочный или файловый доступ в СХД через Ethernet оказывается практичнее FiberChannel и вплотную подобрался по производительности к InfiniBand. Новый же интерфейс еще более усугубит эту ситуацию, фактически сделав все остальные интерфейсы ненужными.
Достоинства:
- Единая сетевая инфраструктура для серверов и СХД -> ниже CAPEX и OPEX
- Высочайшая скорость передачи данных, необходимая для all-flash массивов и СХД большого объема
- Низкая латентность с RDMA и поддержка используемых в СХД протоколов
- Легкое масштабирование
- Удобное управление
- Возможность выбора способа хранения данных (файловый, блочный или объектный) при сохранении единого интерфейса
Ну и наконец о нашем участии в 2550100.
Со своей стороны мы представили коммутатор Eos 720 с 32 QSFP28 портами. Эта модель стала продолжением нашего имеющегося семейства коммутаторов Eos, и создана в рамках любимой нами идеологии BareMetal Switch, то есть обладает установочной средой ONIE, поддерживающей установку различных сетевых ОС. Коммутатор уже полностью готов и в ближайшее время будет доступен в нашей лаборатории, что же касается поддержки со стороны ОС, то мы сейчас плотно сотрудничаем с их производителями по вопросам совместимости.
Основные характеристики у коммутатора таковы:
- 32 порта 100G QSFP28 / 128 25GbE SFP28 с применением breakout кабелей
- Коммутационная матрица 3,2Tbps Broadcom Tomahawk BCM56960, скорость перенаправления 64-байтных пакетов: 2400 Mpps
- Процессор Intel Atom 2538
- Таблица MAC адресов – 136К Unified Forwarding Table (UFT)
- задержка менее 500 нс (PHY-less)
- аппаратная обработка VXLAN/NVGRE
- Оптимизация для ЦОД: 802.1Qau, 802.1Qaz, 802.1Qbb, DCBX, EVB(802.1Qbg), MLAG, 32-way ECMP
- BMS платформа с ONIE: поддерживаются Cumulus Linux (после обновления), Broadcom ICOS (в ноябре)
- Поддержка SDN-коммутации: OpenFlow 1.0, 1.2, 1.3, Open API
- Поддержка инструментария Broadview для полного контроля над сетью
- Отказоустойчивое питание по схеме 1+1
Так что подводя итоги можно сказать, что новый стандарт уже полностью готов к приходу на рынок и в течение года стоит ожидать массового появления коммерческих продуктов. Так что планировать свою инфраструктуру стоит уже сейчас.
Комментарии (49)
RicoX
01.06.2015 22:00Что касается готовности нового стандарта к массовому производству и внедрению, то здесь, на наш взгляд, все обстоит достаточно неплохо. Уже сейчас существует реализованный в железе, текстолите и кремнии полный спектр необходимого оборудования
Можно пример готовых к стандарту маршрутизаторов и брасов?
ETegro_Technologies Автор
02.06.2015 03:58Cisco, Juniper, Alcatel-Lucent, Brocade, H3C, Huawei, ZTE — сколько угодно роутеров на любой вкус и цвет.
BRAS — кому он такой нужен?
norguhtar
>Процессор Intel Atom 2538
Закапывайте.
ETegro_Technologies Автор
Аргументируйте, пожалуйста.
igordata
Можно перефразировать: «А почему у вас используется процессор Atom 2538?» И тогда по всем правилам, доказательство постулата ложится на плечи постулирующего. Могу предположить, что там усё у ней внутрях тотально железно-аппаратное, и поэтому на плечи Атома ложится только координация этих железяк между собой.
DancingOnWater
Ну тогда по всем канонам клинча в ответ услышите: «Священное право на собственные убеждения и личное мнение».
norguhtar
Там наличествует SDN. Он подразумевает, что в случае если правила нет на поток, то это все валит процессору, который обращается к контроллеру и тот говорит какое правило настроить фабрику. Плюс классическая схема подразумевает, что часть потока может быть отправлена на процессор общего назначения и обработана там. Это кстати ответ почему у cisco на их железяках был весьма дохлый NAT при прочих довольно хороших коммутационных характеристиках.
А я вот весьма не уверен, что Intel Atom 2538 сможет с адекватной скоростью обработать возможный поток.
ETegro_Technologies Автор
Это правильное перефразирование. :)
Atom используется потому, что это это архитектура x86, что упрощает перенос собственных дополнительных пакетов в среду сетевой ОС. Альтернативой являются процессоры на архитектурах MIPS и PowerPC.
Вы абсолютно правы, вся работа с трафиком между портами лежит исключительно на коммутирующей матрице, процессор и сетевая ОС нужны лишь для задания правил обработки пакетов матрицей.
Одиночный порт 100GbE практически полностью выедает пропускную способность PCIe x16 v3, «запихать» поток с 32 портов в процессор крайне сложно. Да и возможностей его, мягко говоря, будет несколько недостаточно.
norguhtar
В Linux это никогда проблемой особой не было. А вот стоимость при сравнимых характеристиках может решать, так-как сравнимый даже с Atom MIPS/PowerPC будет стоить несколько дороже.
Т.е. пакеты в сетевую ОС нельзя внутрь отдать от слова никак?
Более того установленный процессор 10GbE имеет риск не прожевать.
ETegro_Technologies Автор
>В Linux это никогда проблемой особой не было. А вот стоимость при сравнимых характеристиках может решать, так-как сравнимый даже с Atom MIPS/PowerPC будет стоить несколько дороже.
Вопрос в стоимости адаптации.
А разница стоимости x86/MIPS/Power несущественна от слова вообще.
>Т.е. пакеты в сетевую ОС нельзя внутрь отдать от слова никак?
На скоростях потока в матрице? Да. Там вся матрица висит на шине PCIe, по которой получает управляющие команды и отдает те данные, которые обучена отдавать. Собственно, вышеупомянутый Broadview введен Boradcom'ом как раз для расширения возможностей работы с трафиком на уровне мониторинга и анализа.
>Более того установленный процессор 10GbE имеет риск не прожевать.
Смотрите чуть ниже. Если нужно именно «жевать» трафик, то для этого сейчас принято ставить специализированные программируемые NPU.
norguhtar
Адаптация чего к чему?
Тогда зачем x86 да еще и с таким количеством памяти?
norguhtar
Процессор весьма дохлый. И что-то внятное сделать на нем нельзя. Грубо говоря если вдруг мне потребуется что-то сделать софтом и пакеты будут уходить к нему, то он много не прожует. Та же ситуация с SDN он может в некоторых случаях не успеть. И получится ситуация «Не прожевал волк бабушку!»
DancingOnWater
А для тех кто в танке можно расчеты и сравнение расчетов и практики у текущего поколения?
ETegro_Technologies Автор
А через что вы собираетесь передавать поток в три терабита в процессор?
Про производительность процессоров можно поговорить отдельно.
norguhtar
Какие три терабита? Он хотя бы 10 гигабит осилит? Вот надо netflow отдавать. Кто этим будет заниматься?
ETegro_Technologies Автор
32 порта х 100 GbE — это физические возможности коммутатора, которые реализованы на коммутационной матрице. Если вы собираетесь выводить поток из нее на обработку процессором — думайте, как вы их туда доставите.
Что же касается производительности x86… ну примерно так:
«Under the tests conducted by SDNCentral testing lab partners, the Brocade Vyatta 5600 vRouter platform ran on a mid-range, Intel Xeon server platform with dual 10-core Xeon processors (E5-2670v2 @ 2.50GHz). The tests measured L3 forwarding for a dual-socket CPU compute node with an aggregate system performance of 70 million packets per second and 80Gbps rates over a wide set of IP conditions – performance was comparable to many traditional hardware appliances.»
Поэтому перестаньте рассчитывать на то, что вы что-то успеете сделать х86-процессором с трафиком такого уровня.
norguhtar
Про то сколько может прожевать x86 процессор я в курсе, по этому и спрашиваю. Вопрос состоит зачем там процессор и что я им смогу сделать с трафиком. Если он там только как рулилка и возможная запускалка процессов, ну ок. Только с таким же успехом можно купить свитч без такого процессора.
ETegro_Technologies Автор
Можно, конечно. Только матрица сама себе правил работы с трафиком не задаст.
norguhtar
Для задачи правил работы с трафиком как-то x86 процессора не надо. Можно обойтись более простым и менее мощным.
ETegro_Technologies Автор
Можно поставить 2-х ядерный Атом.
Было бы желание и объём.
JDima
Дамы и господа, перед нами человек, предположительно никогда не материвший коммутаторы за низкую производительность RP. Уникальный кадр, спешите, смотрите!
Серьезно, после одноядерного камня на 700мгц в sup720 многоядерные относительно современные xeon'ы в нексусах — счастье. Первый можно стабильно загрузить до 100% настройкой SNMP опросов без каких-либо экстремальных таймеров и параметров, второй даже show tech переваривает не замечая нагрузки, за пару-тройку секунд. Обе платформы хардварные, не предполагается передача трафика через те процессоры.
Мне тоже не нравится выбор Атома, но по другой причине: могли бы и чего попроизводительнее впихнуть. Исключительно для control plane — про транзитные пакеты речь не идет.
По поводу упомянутого выше netflow — сам семплинг обычно хардварным делают, на крайняк есть sampled netflow (один пакет из X, где X может быть >100, передается RP, этого достаточно для общего понимания профиля трафика). Процессор только упаковывает уже собранную статистику и шлет коллектору. Иногда даже эта роль переносится на линейные карты, так как задача упаковки готовой статистики в пакеты может серьезно прогрузить RP…
norguhtar
А теперь внимательно почитайте все комментарии :)
Если для этого требуется xeon то я не знаю что мне приложить к лицу, видимо кроме рук еще и ноги :)
Я вообще про производительность тоже писал. Тут или или. Тут или лучше уже больше или же уж можно и ARM поставить. А так получается не рыба не мясо.
JDima
Так у меня рука уже давно приросла к лицу, я давно ничему не удивляюсь. Отображение конфигурации грузит ЦП до 100% секунд на 5-10? Ок, ничего особенного (в конце концов, многие железки не просто файл читают, а по большей части реверсят то, что запрограммировано в железо). Отображение конфигурации отрабатывает мгновенно? Вот это уже необычно.
Какой смысл ставить ARM? Atom похож по производительности и по энергопотреблению. Следить за кодом сразу под две разные архитектуры — затратнее.
norguhtar
У них там linux. Никакой разницы, а ARM кстати по энергопотреблению получше будет :)
JDima
Linux — просто ядро. Есть еще и управляющий софт, который иногда довольно низкоуровнево пишут. И еще очень часто Linux там с RT вставками.
ARM сравним с Atom'ом.
www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient/2
Вообще, железка будет тратить на один порт больше, чем на весь процессор в пике. Что тут сравнивать?
norguhtar
Не в их случае. Управлятор же.
Тогда вообще не понятно зачем Atom.
JDima
И чо? Если управлятор излишне задумывается о чем-то постороннем, то рвутся соседства и теряется трафик.
Так ведь потому что стоит копейки.
norguhtar
И чо? Если управлятор излишне задумывается о чем-то постороннем, то рвутся соседства и теряется трафик.
Ну давайте вместо того чтобы нормально писать код просто ставить жирный процессор. Это же проще :]
JDima
Какое отношение это имеет к качеству кода?
norguhtar
Вообще прямое. Вы просто не представляете как быдлокодом можно легко и не принужденно увеличить системные требования раза в два.
JDima
Всегда будут задачи, требующие как минимум нескольких секунд процессорного времени, каким бы сильным процессор ни был. Всегда будут другие задачи, которые обязательно должны отработать точно в срок (речь про миллисекунды).
ETegro_Technologies Автор
ARM не будет лучше по потреблению, а единый репозиторий софта гораздо удобней.
norguhtar
Единый репозиторий с чем?
ETegro_Technologies Автор
Оркестровка OpenStack, NFV продукты, автоматизация (Chef и т.д.), агенты sFlow.
Мало ли чего ещё захочется поставить.
У Гугла используется единый образ на все случаи жизни — он разворачивается на железке, по конфигурации понимает, где оказался, и устанавливает нужную роль.
Всё автоматом, без участия человека.
Будут у нас х86 серверы и PPC коммутаторы — так уже не сделать.
norguhtar
Как дистрибутив? Так-то вообще практически для любого дистрибутива есть специальные фабрики позволяющие собирать под что угодно. А уж про openembedded я пожалуй промолчу :)
ETegro_Technologies Автор
Да можно собирать подо всё, что угодно, никто не спорит.
Но зачем тянуть 2 ветки разработки вместо одной?
ilukyanov
Нет никакой разницы ровно до того момента, пока не возникнет необходимость поставить там что-нибудь свое, например какое-нибудь свое приложение на Java и нативные JNI-либы прицепом.
Главный плюс Atom'a именно в том, что это дешевый и слабый, но тем не менее x86 процессор. И разработчикам не нужно думать, как там кросс-компилить софт и как потом все это дело отлаживать.
ilukyanov
К вопросу о совместимости софта под ARMы — из нескольких протестированных моделей (среди которых Marvell и еще одна серверная модель) ни на одной линуксовый AIO не работает так, как работает на x86 (включая Atom). Тесты, которые на Atom'е съедают 10-15% CPU, все без исключения ARMы уводят в глубокий iowait в 60-80%.
Это в принципе все что нужно знать о зрелости армовой экосистемы.
equand
Netmap наше все в данном случае.
JDima
Каким боком он «все в данном случае»? Какое отношение он имеет к задачам RP свитча?
DancingOnWater
Не знаю, общая эрудиция говорит, что в любых процессорах шина не настолько широка, чтоб все пропустить; потому и спрашиваю про сравнение с текущим поколением.
ETegro_Technologies Автор
Коммутатор делится на control plane (управляющая часть) и data plane (коммутирующая часть).
Наиболее удобная аналогия — коммутирующая часть выступает для управляющей устройством на PCIe шине, как GPU либо Xeon Phi.
Связь между ними — хорошо, если PCIe 2.0 x2 и гигабит, вопрос направления каких-либо потоков вообще не стоит.
Нужна управлялка только для программирования матрицы правилами + внешнего софта для оркестровки/автоматизации процесса.
Как появились коммутаторы 10G на Freescale P2020, так и в 100G можно поставить его же.
Атомы пришли в коммутаторы позже, но и они не меняются.
xdeller
Ну, немного о цифрах — у 100GE с обычным 1536b пакетами скорость классификации близка к 10Mpps — далеко не все современные фреймворки способны переваривать такой рейт на чем-то, кроме топовых процессоров. Если вас вдруг начнут атаковать и пакет рейт вырастет на порядок — x86 просто не будет способен это переварить, по нескольким причинам:
а) нельзя масштабироваться на соседние NUMA-ноды, то есть сокеты, слишком большие потери даже при bulk queuing пакетов для пересылки между процессором и очередями карт, сюда же записываем проблему с работой DCA, который хорошо вывозит работу с картой на сравнительно небольших объемах трафика,
б) классификация пакетов не может съедать ниже определенного числа тактов на пакет, равного примерно полусотне.
Иными словами, хотите крутой и производительный SDN — распределяйте обработку пакетов по коробкам, а там уже не имеет значения, атом ли это или топовый зеон. В сабжевом устройстве единственная задача управляющей платы — запускать линукс с программирующей сущностью, обычно это сцепленный с API матрицы виртуальный свич.
norguhtar
Про то и речь.
Иными словами, а зачем тогда тут Atom? :)
С моей точки зрения ставить туда тогда 4 ядерный Atom с 8 гигабайтами памяти под такую задачу несколько избыточно. Не проще ARM туда воткнуть или MIPS?
ETegro_Technologies Автор
>С моей точки зрения ставить туда тогда 4 ядерный Atom с 8 гигабайтами памяти под такую задачу несколько избыточно.
Пакеты мониторинга, управления и оркестрации нынче становятся весьма требовательными. Проще сразу заложить некоторый запас, чем сэкономить копейки на железе, а потом страдать, не влезая в пожелания заказчика.
Собственно, архитектуру процессора можно подобрать под конкретного заказчика, если он уже имеет широкомасштабную развернутую структуру. Оно же все реализуется на дочерних платах, как завещает OCP, и пророк его Facebook.
norguhtar
Настолько? Не ну если на ruby писать то конечно и такого процессора будет мало.
Atom вынули, MIPS, ARM поставили?
ETegro_Technologies Автор
>Настолько? Не ну если на ruby писать то конечно и такого процессора будет мало.
Нет границ у таланта индусокодеров!
>Atom вынули, MIPS, ARM поставили?
Практически.
Плата с красным тексталитом — «серверная» часть: впаянный процессор, RAM, флеш.
hsto.org/getpro/habr/post_images/404/0b9/1c0/4040b91c057566d811980065feb4dcd0.jpg
norguhtar
Ну учитывая размер, что-то другое в x86 сложновато будет впихнуть, хотя можно.
ETegro_Technologies Автор
Можно поставить 8-ядерный атом, благо ничего менять не надо.