Comments 21
Вполне ожидаемый шаг со стороны вендоров, с моей точки зрения.
Скоро увидим Cisco ASR с dd-wrt и коммутатор extrime networks с прошивкой от dlink :)
>в котором утверждалось, что «8 из 10 самых крупных интернет-компаний являются клиентами Cisco», а Facebook создает собственные сервера потому что «компания может удовлетворить некоторые уникальные требования только с помощью собственных разработок».
Так ведь правду пишут.
1) Компании уровня Google и Facebook — это не только ЦОД, но и десятки/сотни тысяч сотрудников, имеющих IP телефоны, желающих покушать вайфай и т.д. Многие забывают, что кроме ЦОДа есть еще и кампус. Все гиганты ставят туда самое обычное железо, те же шеститонники например, и используют на них самый обычный софт. Всё потому что в кампусе от софта не требуется каких-либо извращений, пакеты по FIB гоняет — и ладно.
2) Да, у FB и Google есть свои уникальные требования, и да, они не хотят зависеть от вендора. Их право. Многие другие крупные компании говорят вендору «мы купим у вас железа на 8-значный ценник, за это вы дадите нам такой-то и такой-то функционал», и обычно вендор этот функционал спешно кодит.
>На самом же деле ничего уникального в идее перехода на собственное оборудование нет.
Есть. Это очень дорого и сложно, лишь компании с очень сильным штатом разработчиков могут себе это позволить.
>Скоро увидим Cisco ASR с dd-wrt
Свят-свят… Он и с родным софтом глючит как каналья… Тысячник по крайней мере.
Так ведь правду пишут.
1) Компании уровня Google и Facebook — это не только ЦОД, но и десятки/сотни тысяч сотрудников, имеющих IP телефоны, желающих покушать вайфай и т.д. Многие забывают, что кроме ЦОДа есть еще и кампус. Все гиганты ставят туда самое обычное железо, те же шеститонники например, и используют на них самый обычный софт. Всё потому что в кампусе от софта не требуется каких-либо извращений, пакеты по FIB гоняет — и ладно.
2) Да, у FB и Google есть свои уникальные требования, и да, они не хотят зависеть от вендора. Их право. Многие другие крупные компании говорят вендору «мы купим у вас железа на 8-значный ценник, за это вы дадите нам такой-то и такой-то функционал», и обычно вендор этот функционал спешно кодит.
>На самом же деле ничего уникального в идее перехода на собственное оборудование нет.
Есть. Это очень дорого и сложно, лишь компании с очень сильным штатом разработчиков могут себе это позволить.
>Скоро увидим Cisco ASR с dd-wrt
Свят-свят… Он и с родным софтом глючит как каналья… Тысячник по крайней мере.
Я очень надеюсь и жду момента, когда сервера можно будет комплектовать не только sas-бэкплейнами, но и коммутационными бэкплейнами на 48 портов.
Фактический управляемый коммутатор уже давно состоит из switch plane (весь из себя аппаратный и программируемый) и management plane (который весь из себя компьютер).
Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства. А вот специализацию имеет смысл как раз в эти самые коммутирующие бэкплейны выпихивать. Количество возможностей, которое это открывает, трудно себе представить. Например, распределённый load ballancer может брать на себя часть нагрузки, а ту часть, которую не взял, коммутировать дальше по цепочке, к другим балансерам.
Виртуализаторы будут тоже очень счастливы, ибо коммутатор, наконец-таки, обзаведётся приличной операционкой и средой для выполнения какого-нибудь питона.
SDN, само собой.
Фактический управляемый коммутатор уже давно состоит из switch plane (весь из себя аппаратный и программируемый) и management plane (который весь из себя компьютер).
Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства. А вот специализацию имеет смысл как раз в эти самые коммутирующие бэкплейны выпихивать. Количество возможностей, которое это открывает, трудно себе представить. Например, распределённый load ballancer может брать на себя часть нагрузки, а ту часть, которую не взял, коммутировать дальше по цепочке, к другим балансерам.
Виртуализаторы будут тоже очень счастливы, ибо коммутатор, наконец-таки, обзаведётся приличной операционкой и средой для выполнения какого-нибудь питона.
SDN, само собой.
Виртуализаторы будут тоже очень счастливы, ибо коммутатор, наконец-таки, обзаведётся приличной операционкой и средой для выполнения какого-нибудь питона.
да есть все это уже ) в той же NX-OS, к примеру
Приличной операционкой. apt-get install, всё такое. Какие-то подвижки в этом вопросе есть, но вот так вот с бухты-барахты адаптировать существующую ОС к нестандартному железу не получится, так что там либо гвоздями прибито, либо самодельное и уж очень простенькое.
>apt-get install, всё такое.
Это как раз все тот же упомянутый в посте Cumulus, про который мы регулярно пишем.
По архитектуре… тот же наш Eos 420 внутри имеет совершенно классический x86 Intel Atom C2758. Главная проблема — как раз в районе switch plane, где никто особо не горит желанием отдавать в открытое сообщество работу с матрицей. Так чисто любопытства ради стоит заглянуть на opennetlinux.org/ и посмотреть, что у них с новостями, что с доступностью SDK для работы с матрицами (подсказка: смотреть в FAQ).
Сервер с коммутационным бэкплейном — идея красивая, конечно, но востребованность у нее сомнительная.
Это как раз все тот же упомянутый в посте Cumulus, про который мы регулярно пишем.
По архитектуре… тот же наш Eos 420 внутри имеет совершенно классический x86 Intel Atom C2758. Главная проблема — как раз в районе switch plane, где никто особо не горит желанием отдавать в открытое сообщество работу с матрицей. Так чисто любопытства ради стоит заглянуть на opennetlinux.org/ и посмотреть, что у них с новостями, что с доступностью SDK для работы с матрицами (подсказка: смотреть в FAQ).
Сервер с коммутационным бэкплейном — идея красивая, конечно, но востребованность у нее сомнительная.
А почему Atom, а не парочка топовых зеонов с полутерабайтом памяти?
Потому что этого атома с избытком хватает на потребности ОС в том случае, если сетевой трафик не надо гонять на процессор и обратно и он бегает в пределах портов и ASIC'а.
А парочка даже не самых топовых зеонов с четвертью терабайта памяти уже удваивает цену коммутатора (а это 48 х 10G). Пока не видно сколько-нибудь значимого количества клиентов, желающих оплачивать создание такого удовольствия. А главное, не очень понятно зачем оно такое: какие вы видите задачи, чтобы их в принципе было выгодно решать на дорогостоящей (по энергопотреблению и стоимости обработки трафика) универсальной архитектуре и нельзя было реализовать на NPU?
А парочка даже не самых топовых зеонов с четвертью терабайта памяти уже удваивает цену коммутатора (а это 48 х 10G). Пока не видно сколько-нибудь значимого количества клиентов, желающих оплачивать создание такого удовольствия. А главное, не очень понятно зачем оно такое: какие вы видите задачи, чтобы их в принципе было выгодно решать на дорогостоящей (по энергопотреблению и стоимости обработки трафика) универсальной архитектуре и нельзя было реализовать на NPU?
Потому что вы сейчас описываете решение задач, которые успешно решаются существующими решениями.
Я бы не отказался видеть такой гибрид свитча с сервером в openstack'е в качестве сетевой ноды. Благодаря link-local уровню связности, load balancer может реагировать на даун сервера, который с ним связан прямым проводом, со скоростью среды и направлять трафик между бэкэндами с почти нулевыми накладными расходами (то есть в контексте 48 10-Гб портов — одна-две таких штук могла бы обслуживать практически неограниченный объём трафика, так как от быстрого процессора требовалось бы всего лишь обрабатывать 40-50 Mrps в пике, при этом реальный tcp держали бы бэкэнды, а не бедный балансер.
Я бы не отказался видеть такой гибрид свитча с сервером в openstack'е в качестве сетевой ноды. Благодаря link-local уровню связности, load balancer может реагировать на даун сервера, который с ним связан прямым проводом, со скоростью среды и направлять трафик между бэкэндами с почти нулевыми накладными расходами (то есть в контексте 48 10-Гб портов — одна-две таких штук могла бы обслуживать практически неограниченный объём трафика, так как от быстрого процессора требовалось бы всего лишь обрабатывать 40-50 Mrps в пике, при этом реальный tcp держали бы бэкэнды, а не бедный балансер.
Вы не учитываете, чем матрица связана с управляющей частью.
PCIe Gen2 x4, в лучшем случае и это именно интерфейс для программирования матрицы. При большом желании можно, наверное, обработку трафика тоже через него гонять, но это нетривиальная задача.
PCIe Gen2 x4, в лучшем случае и это именно интерфейс для программирования матрицы. При большом желании можно, наверное, обработку трафика тоже через него гонять, но это нетривиальная задача.
Это же исправимо, не? PCI-E x16.
Кроме того, если такой LB будет балансировать, то ему не надо будет получать весь фид в control plane. Он будет инспектировать заголовки flow, а дальше вся flow идти в режиме коммутации на нужный сервер.
Итого — в нормальном режиме, раздавая файлы по 125кб, и общем фиде в 240Гбит (240000 файлов в секунду) надо будет обслуживать жалкие 240к пакетов от заголовков flow. Что совсем не «жалкие», но добротный коннект по PCI и быстрые процы — вполне переварят. По 15к балансировок на ядро — очень даже гуманно.
Кроме того, если такой LB будет балансировать, то ему не надо будет получать весь фид в control plane. Он будет инспектировать заголовки flow, а дальше вся flow идти в режиме коммутации на нужный сервер.
Итого — в нормальном режиме, раздавая файлы по 125кб, и общем фиде в 240Гбит (240000 файлов в секунду) надо будет обслуживать жалкие 240к пакетов от заголовков flow. Что совсем не «жалкие», но добротный коннект по PCI и быстрые процы — вполне переварят. По 15к балансировок на ядро — очень даже гуманно.
>>но и коммутационными бэкплейнами на 48 портов.
Не нужно это, делать отдельный подвид ящиков сейчас нет смысла. Слишком специфична коммутационная часть.
>> Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Посмотрите на современный коммутатор — там уже стоят массовые PPC или Intel Atom, ось кидается на SSD, а за управление матрицей отвечает драйвер :)
На тот же Cumulus Linux можно ставить любой сторонний софт.
Не нужно это, делать отдельный подвид ящиков сейчас нет смысла. Слишком специфична коммутационная часть.
>> Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Посмотрите на современный коммутатор — там уже стоят массовые PPC или Intel Atom, ось кидается на SSD, а за управление матрицей отвечает драйвер :)
На тот же Cumulus Linux можно ставить любой сторонний софт.
В этом и проблема, в них ставят обычно унылое Г, а во многих применениях хочется иметь что-то приличное, с кучей ядер, кучей памяти и т.д.
Короче, генерализация сетевого оборудования, как «переферия для сервера» может дать существенные изменения. А, главное, размыть network wall.
Короче, генерализация сетевого оборудования, как «переферия для сервера» может дать существенные изменения. А, главное, размыть network wall.
Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Вы не поверите на сколько вы близки к истине. Juniper вообще изначально имеет на борту комп x86 с переработанной FreeBSD и не скрывает этого, а к компу присоединен DataPlane, который через шину (и драйвер) общается с ОС в обоих направлениях. CISCO тоже раньше ставила процы от моторолы, а на днях довелось разобрать (вроде 3750) коммутатор, так там intel и amd (я так понимаю от серии зависит) на MCU уже давно.
Давно пора
Было бы неплохо ссылку на оригинал с Wired.
Sign up to leave a comment.
Как интернет-гиганты перевернули бизнес по продаже сетевого «железа»