Эволюция сетей — новый стандарт 25/50/100 GbE

    Современные сети 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 работают на аплинк.

    Достоинства такого решения:
    • На 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

      +3
      >Процессор Intel Atom 2538
      Закапывайте.
        +1
        Аргументируйте, пожалуйста.
          +3
          Можно перефразировать: «А почему у вас используется процессор Atom 2538?» И тогда по всем правилам, доказательство постулата ложится на плечи постулирующего. Могу предположить, что там усё у ней внутрях тотально железно-аппаратное, и поэтому на плечи Атома ложится только координация этих железяк между собой.
            0
            Ну тогда по всем канонам клинча в ответ услышите: «Священное право на собственные убеждения и личное мнение».
              0
              Там наличествует SDN. Он подразумевает, что в случае если правила нет на поток, то это все валит процессору, который обращается к контроллеру и тот говорит какое правило настроить фабрику. Плюс классическая схема подразумевает, что часть потока может быть отправлена на процессор общего назначения и обработана там. Это кстати ответ почему у cisco на их железяках был весьма дохлый NAT при прочих довольно хороших коммутационных характеристиках.

              А я вот весьма не уверен, что Intel Atom 2538 сможет с адекватной скоростью обработать возможный поток.
                +3
                Это правильное перефразирование. :)
                Atom используется потому, что это это архитектура x86, что упрощает перенос собственных дополнительных пакетов в среду сетевой ОС. Альтернативой являются процессоры на архитектурах MIPS и PowerPC.

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

                Одиночный порт 100GbE практически полностью выедает пропускную способность PCIe x16 v3, «запихать» поток с 32 портов в процессор крайне сложно. Да и возможностей его, мягко говоря, будет несколько недостаточно.
                  0
                  Atom используется потому, что это это архитектура x86, что упрощает перенос собственных дополнительных пакетов в среду сетевой ОС. Альтернативой являются процессоры на архитектурах MIPS и PowerPC.

                  В Linux это никогда проблемой особой не было. А вот стоимость при сравнимых характеристиках может решать, так-как сравнимый даже с Atom MIPS/PowerPC будет стоить несколько дороже.

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

                  Т.е. пакеты в сетевую ОС нельзя внутрь отдать от слова никак?

                  Одиночный порт 100GbE практически полностью выедает пропускную способность PCIe x16 v3, «запихать» поток с 32 портов в процессор крайне сложно. Да и возможностей его, мягко говоря, будет несколько недостаточно.

                  Более того установленный процессор 10GbE имеет риск не прожевать.
                    +2
                    >В Linux это никогда проблемой особой не было. А вот стоимость при сравнимых характеристиках может решать, так-как сравнимый даже с Atom MIPS/PowerPC будет стоить несколько дороже.

                    Вопрос в стоимости адаптации.
                    А разница стоимости x86/MIPS/Power несущественна от слова вообще.

                    >Т.е. пакеты в сетевую ОС нельзя внутрь отдать от слова никак?
                    На скоростях потока в матрице? Да. Там вся матрица висит на шине PCIe, по которой получает управляющие команды и отдает те данные, которые обучена отдавать. Собственно, вышеупомянутый Broadview введен Boradcom'ом как раз для расширения возможностей работы с трафиком на уровне мониторинга и анализа.

                    >Более того установленный процессор 10GbE имеет риск не прожевать.
                    Смотрите чуть ниже. Если нужно именно «жевать» трафик, то для этого сейчас принято ставить специализированные программируемые NPU.
                      0
                      Вопрос в стоимости адаптации.

                      Адаптация чего к чему?

                      Смотрите чуть ниже. Если нужно именно «жевать» трафик, то для этого сейчас принято ставить специализированные программируемые NPU.

                      Тогда зачем x86 да еще и с таким количеством памяти?
                –2
                Процессор весьма дохлый. И что-то внятное сделать на нем нельзя. Грубо говоря если вдруг мне потребуется что-то сделать софтом и пакеты будут уходить к нему, то он много не прожует. Та же ситуация с SDN он может в некоторых случаях не успеть. И получится ситуация «Не прожевал волк бабушку!»
                  0
                  А для тех кто в танке можно расчеты и сравнение расчетов и практики у текущего поколения?
                    +1
                    А через что вы собираетесь передавать поток в три терабита в процессор?

                    Про производительность процессоров можно поговорить отдельно.
                      –2
                      Какие три терабита? Он хотя бы 10 гигабит осилит? Вот надо netflow отдавать. Кто этим будет заниматься?
                        0
                        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-процессором с трафиком такого уровня.
                          0
                          Про то сколько может прожевать x86 процессор я в курсе, по этому и спрашиваю. Вопрос состоит зачем там процессор и что я им смогу сделать с трафиком. Если он там только как рулилка и возможная запускалка процессов, ну ок. Только с таким же успехом можно купить свитч без такого процессора.
                            0
                            Можно, конечно. Только матрица сама себе правил работы с трафиком не задаст.
                              0
                              Для задачи правил работы с трафиком как-то x86 процессора не надо. Можно обойтись более простым и менее мощным.
                                0
                                Можно поставить 2-х ядерный Атом.
                                Было бы желание и объём.
                                  +4
                                  Дамы и господа, перед нами человек, предположительно никогда не материвший коммутаторы за низкую производительность RP. Уникальный кадр, спешите, смотрите!

                                  Серьезно, после одноядерного камня на 700мгц в sup720 многоядерные относительно современные xeon'ы в нексусах — счастье. Первый можно стабильно загрузить до 100% настройкой SNMP опросов без каких-либо экстремальных таймеров и параметров, второй даже show tech переваривает не замечая нагрузки, за пару-тройку секунд. Обе платформы хардварные, не предполагается передача трафика через те процессоры.

                                  Мне тоже не нравится выбор Атома, но по другой причине: могли бы и чего попроизводительнее впихнуть. Исключительно для control plane — про транзитные пакеты речь не идет.

                                  По поводу упомянутого выше netflow — сам семплинг обычно хардварным делают, на крайняк есть sampled netflow (один пакет из X, где X может быть >100, передается RP, этого достаточно для общего понимания профиля трафика). Процессор только упаковывает уже собранную статистику и шлет коллектору. Иногда даже эта роль переносится на линейные карты, так как задача упаковки готовой статистики в пакеты может серьезно прогрузить RP…
                                    –3
                                    Дамы и господа, перед нами человек, предположительно никогда не материвший коммутаторы за низкую производительность

                                    А теперь внимательно почитайте все комментарии :)

                                    Серьезно, после одноядерного камня на 700мгц в sup720 многоядерные относительно современные xeon'ы в нексусах — счастье. Первый можно стабильно загрузить до 100% настройкой SNMP опросов без каких-либо экстремальных таймеров и параметров, второй даже show tech переваривает не замечая нагрузки, за пару-тройку секунд.

                                    Если для этого требуется xeon то я не знаю что мне приложить к лицу, видимо кроме рук еще и ноги :)

                                    Мне тоже не нравится выбор Атома, но по другой причине: могли бы и чего попроизводительнее впихнуть. Исключительно для control plane — про транзитные пакеты речь не идет.

                                    Я вообще про производительность тоже писал. Тут или или. Тут или лучше уже больше или же уж можно и ARM поставить. А так получается не рыба не мясо.
                                      +2
                                      Если для этого требуется xeon то я не знаю что мне приложить к лицу, видимо кроме рук еще и ноги

                                      Так у меня рука уже давно приросла к лицу, я давно ничему не удивляюсь. Отображение конфигурации грузит ЦП до 100% секунд на 5-10? Ок, ничего особенного (в конце концов, многие железки не просто файл читают, а по большей части реверсят то, что запрограммировано в железо). Отображение конфигурации отрабатывает мгновенно? Вот это уже необычно.

                                      или же уж можно и ARM поставить. А так получается не рыба не мясо.

                                      Какой смысл ставить ARM? Atom похож по производительности и по энергопотреблению. Следить за кодом сразу под две разные архитектуры — затратнее.
                                        –3
                                        У них там linux. Никакой разницы, а ARM кстати по энергопотреблению получше будет :)
                                          +1
                                          Linux — просто ядро. Есть еще и управляющий софт, который иногда довольно низкоуровнево пишут. И еще очень часто Linux там с RT вставками.

                                          ARM сравним с Atom'ом.

                                          www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient/2

                                          Вообще, железка будет тратить на один порт больше, чем на весь процессор в пике. Что тут сравнивать?
                                            0
                                            Linux — просто ядро. Есть еще и управляющий софт, который иногда довольно низкоуровнево пишут. И еще очень часто Linux там с RT вставками.

                                            Не в их случае. Управлятор же.

                                            Вообще, железка будет тратить на один порт больше, чем на весь процессор в пике. Что тут сравнивать?

                                            Тогда вообще не понятно зачем Atom.
                                              0
                                              Не в их случае. Управлятор же

                                              И чо? Если управлятор излишне задумывается о чем-то постороннем, то рвутся соседства и теряется трафик.
                                              Тогда вообще не понятно зачем Atom.

                                              Так ведь потому что стоит копейки.
                                                0
                                                И чо? Если управлятор излишне задумывается о чем-то постороннем, то рвутся соседства и теряется трафик.

                                                Ну давайте вместо того чтобы нормально писать код просто ставить жирный процессор. Это же проще :]
                                                  0
                                                  Какое отношение это имеет к качеству кода?
                                                    –1
                                                    Вообще прямое. Вы просто не представляете как быдлокодом можно легко и не принужденно увеличить системные требования раза в два.
                                                      0
                                                      Всегда будут задачи, требующие как минимум нескольких секунд процессорного времени, каким бы сильным процессор ни был. Всегда будут другие задачи, которые обязательно должны отработать точно в срок (речь про миллисекунды).
                                            0
                                            ARM не будет лучше по потреблению, а единый репозиторий софта гораздо удобней.
                                              0
                                              Единый репозиторий с чем?
                                                0
                                                Оркестровка OpenStack, NFV продукты, автоматизация (Chef и т.д.), агенты sFlow.
                                                Мало ли чего ещё захочется поставить.

                                                У Гугла используется единый образ на все случаи жизни — он разворачивается на железке, по конфигурации понимает, где оказался, и устанавливает нужную роль.
                                                Всё автоматом, без участия человека.

                                                Будут у нас х86 серверы и PPC коммутаторы — так уже не сделать.
                                                  0
                                                  Оркестровка OpenStack, NFV продукты, автоматизация (Chef и т.д.), агенты sFlow.
                                                  Мало ли чего ещё захочется поставить.

                                                  Как дистрибутив? Так-то вообще практически для любого дистрибутива есть специальные фабрики позволяющие собирать под что угодно. А уж про openembedded я пожалуй промолчу :)
                                                    0
                                                    Да можно собирать подо всё, что угодно, никто не спорит.
                                                    Но зачем тянуть 2 ветки разработки вместо одной?
                                              +2
                                              Нет никакой разницы ровно до того момента, пока не возникнет необходимость поставить там что-нибудь свое, например какое-нибудь свое приложение на Java и нативные JNI-либы прицепом.

                                              Главный плюс Atom'a именно в том, что это дешевый и слабый, но тем не менее x86 процессор. И разработчикам не нужно думать, как там кросс-компилить софт и как потом все это дело отлаживать.

                                                +2
                                                К вопросу о совместимости софта под ARMы — из нескольких протестированных моделей (среди которых Marvell и еще одна серверная модель) ни на одной линуксовый AIO не работает так, как работает на x86 (включая Atom). Тесты, которые на Atom'е съедают 10-15% CPU, все без исключения ARMы уводят в глубокий iowait в 60-80%.

                                                Это в принципе все что нужно знать о зрелости армовой экосистемы.
                                            0
                                            Netmap наше все в данном случае.
                                              +2
                                              Каким боком он «все в данном случае»? Какое отношение он имеет к задачам RP свитча?
                                  0
                                  Не знаю, общая эрудиция говорит, что в любых процессорах шина не настолько широка, чтоб все пропустить; потому и спрашиваю про сравнение с текущим поколением.
                                    0
                                    Коммутатор делится на control plane (управляющая часть) и data plane (коммутирующая часть).
                                    Наиболее удобная аналогия — коммутирующая часть выступает для управляющей устройством на PCIe шине, как GPU либо Xeon Phi.

                                    Связь между ними — хорошо, если PCIe 2.0 x2 и гигабит, вопрос направления каких-либо потоков вообще не стоит.
                                    Нужна управлялка только для программирования матрицы правилами + внешнего софта для оркестровки/автоматизации процесса.
                                    Как появились коммутаторы 10G на Freescale P2020, так и в 100G можно поставить его же.
                                    Атомы пришли в коммутаторы позже, но и они не меняются.
                                  +1
                                  Ну, немного о цифрах — у 100GE с обычным 1536b пакетами скорость классификации близка к 10Mpps — далеко не все современные фреймворки способны переваривать такой рейт на чем-то, кроме топовых процессоров. Если вас вдруг начнут атаковать и пакет рейт вырастет на порядок — x86 просто не будет способен это переварить, по нескольким причинам:
                                  а) нельзя масштабироваться на соседние NUMA-ноды, то есть сокеты, слишком большие потери даже при bulk queuing пакетов для пересылки между процессором и очередями карт, сюда же записываем проблему с работой DCA, который хорошо вывозит работу с картой на сравнительно небольших объемах трафика,
                                  б) классификация пакетов не может съедать ниже определенного числа тактов на пакет, равного примерно полусотне.

                                  Иными словами, хотите крутой и производительный SDN — распределяйте обработку пакетов по коробкам, а там уже не имеет значения, атом ли это или топовый зеон. В сабжевом устройстве единственная задача управляющей платы — запускать линукс с программирующей сущностью, обычно это сцепленный с API матрицы виртуальный свич.
                                    0
                                    100GE с обычным 1536b пакетами скорость классификации близка к 10Mpps — далеко не все современные фреймворки способны переваривать такой рейт на чем-то, кроме топовых процессоров.

                                    Про то и речь.

                                    Иными словами, хотите крутой и производительный SDN — распределяйте обработку пакетов по коробкам, а там уже не имеет значения, атом ли это или топовый зеон.

                                    Иными словами, а зачем тогда тут Atom? :)

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

                                    С моей точки зрения ставить туда тогда 4 ядерный Atom с 8 гигабайтами памяти под такую задачу несколько избыточно. Не проще ARM туда воткнуть или MIPS?
                                      0
                                      >С моей точки зрения ставить туда тогда 4 ядерный Atom с 8 гигабайтами памяти под такую задачу несколько избыточно.

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

                                      Собственно, архитектуру процессора можно подобрать под конкретного заказчика, если он уже имеет широкомасштабную развернутую структуру. Оно же все реализуется на дочерних платах, как завещает OCP, и пророк его Facebook.
                                        0
                                        Пакеты мониторинга, управления и оркестрации нынче становятся весьма требовательными. Проще сразу заложить некоторый запас, чем сэкономить копейки на железе, а потом страдать, не влезая в пожелания заказчика.

                                        Настолько? Не ну если на ruby писать то конечно и такого процессора будет мало.

                                        Оно же все реализуется на дочерних платах, как завещает OCP, и пророк его Facebook.

                                        Atom вынули, MIPS, ARM поставили?
                                          0
                                          >Настолько? Не ну если на ruby писать то конечно и такого процессора будет мало.

                                          Нет границ у таланта индусокодеров!

                                          >Atom вынули, MIPS, ARM поставили?

                                          Практически.

                                          Плата с красным тексталитом — «серверная» часть: впаянный процессор, RAM, флеш.

                                          hsto.org/getpro/habr/post_images/404/0b9/1c0/4040b91c057566d811980065feb4dcd0.jpg
                                            0
                                            Ну учитывая размер, что-то другое в x86 сложновато будет впихнуть, хотя можно.
                                              0
                                              Можно поставить 8-ядерный атом, благо ничего менять не надо.
                              0
                              Что касается готовности нового стандарта к массовому производству и внедрению, то здесь, на наш взгляд, все обстоит достаточно неплохо. Уже сейчас существует реализованный в железе, текстолите и кремнии полный спектр необходимого оборудования

                              Можно пример готовых к стандарту маршрутизаторов и брасов?
                                0
                                Cisco, Juniper, Alcatel-Lucent, Brocade, H3C, Huawei, ZTE — сколько угодно роутеров на любой вкус и цвет.
                                BRAS — кому он такой нужен?

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое