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 можно ставить любой сторонний софт.
Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Вы не поверите на сколько вы близки к истине. Juniper вообще изначально имеет на борту комп x86 с переработанной FreeBSD и не скрывает этого, а к компу присоединен DataPlane, который через шину (и драйвер) общается с ОС в обоих направлениях. CISCO тоже раньше ставила процы от моторолы, а на днях довелось разобрать (вроде 3750) коммутатор, так там intel и amd (я так понимаю от серии зависит) на MCU уже давно.
Давно пора
Было бы неплохо ссылку на оригинал с Wired.
Sign up to leave a comment.
Как интернет-гиганты перевернули бизнес по продаже сетевого «железа»