IaaS, VPS, VDS, Частное и публичное облако, SSL
168,04
рейтинг
25 февраля 2015 в 17:50

Разное → Как интернет-гиганты перевернули бизнес по продаже сетевого «железа» перевод

image

Google, Facebook и Amazon не продают коммутаторы и никогда не будут этим заниматься. Однако этим компаниям удалось изменить то, как такое оборудование продают другие.

Без коммутаторов («свитчей») невозможно представить себе работу интернета — ведь именно с их помощью огромные объемы данных пересылаются между дата-центрами и частными сетями. Традиционно, на рынке продажи этих устройств доминировали большие американские компании вроде Cisco и Juniper — они предлагают покупателям довольно дорогое оборудование, работающее на проприетарном софте.

Но традиционное устройство этого рынка постепенно стало все более неудобным для растущих Google, Facebook и Amazon. Оборудование американских компаний было слишком дорогим и сложным в настройке, поэтому интернет-гиганты обратили свой взор на продавцов «железа» из Азии.

Прежде всего, им удалось договориться об установке на оборудование азиатских производителей «кастомных» прошивок. Сначала производители неохотно соглашались на подобную практику (и позднее некоторые от нее отказались вовсе, поскольку создавать свой подобный софт могут только ИТ-гиганты). Однако позднее рынок потянулся в эту сторону.

На прошлой неделе HP объявила о том, что начнет продавать «только железные» (то есть без софта) коммутаторы, на которые любой желающий сможет установить своей собственное программное обеспечение. На первый взгляд, не слишком впечатляющая новость, однако она говорит об огромном сдвиге всей парадигмы рынка сетевых устройств. В деле предоставления покупателям «голого» железа HP идет вслед за Juniper и Dell.

«Все происходит куда быстрее, чем я представлял», — говорит Джей Ар Риверс (JR Rivers), CEO Cumulus Networks, стартапа, который создает программное обеспечение для коммутаторов — этот софт HP также собирается предлагать своим клиентам.

image

Джей Ар Риверс

Некоторе время Риверс работал над созданием сетевого оборудования в Google, а теперь продвигает те же самые идеи на всем рынке в целом. Google создавал свитчи, на которое можно установить собственное сетевое ПО и в дальнейшем обновлять его, теперь Cumulus помогает другим компаниям делать то же самое.

Пару недель назад соцсеть Facebook объявила о переводе своих дата-центров на разработанные внутри компании коммутаторы и софт для управления ими.

image

Модульный коммутатор Facebook под названием «6-pack»

Складывающейся ситуацией явно обеспокоены в Cisco, считают журналисты Wired, ведь сразу после новости от Facebook, производитель сетевого оборудования прислал в издание пресс-релиз, в котором утверждалось, что «8 из 10 самых крупных интернет-компаний являются клиентами Cisco», а Facebook создает собственные сервера потому что «компания может удовлетворить некоторые уникальные требования только с помощью собственных разработок».

На самом же деле ничего уникального в идее перехода на собственное оборудование нет.

Кейд Метц из Wired считает, что в скором времени рынок сетевого оборудования станет похож на рынок PC и серверов — «железо» и «софт» будут разделены, что позволит клиентам комбинировать их, затачивая под собственные нужды.
Автор: @1cloud CADE METZ
1cloud.ru
рейтинг 168,04
IaaS, VPS, VDS, Частное и публичное облако, SSL

Комментарии (21)

  • 0
    Вполне ожидаемый шаг со стороны вендоров, с моей точки зрения.
  • +9
    Скоро увидим Cisco ASR с dd-wrt и коммутатор extrime networks с прошивкой от dlink :)
    • 0
      с прошивкой от dlink

      Только не это, Шеф, только не это!
  • 0
    >в котором утверждалось, что «8 из 10 самых крупных интернет-компаний являются клиентами Cisco», а Facebook создает собственные сервера потому что «компания может удовлетворить некоторые уникальные требования только с помощью собственных разработок».
    Так ведь правду пишут.
    1) Компании уровня Google и Facebook — это не только ЦОД, но и десятки/сотни тысяч сотрудников, имеющих IP телефоны, желающих покушать вайфай и т.д. Многие забывают, что кроме ЦОДа есть еще и кампус. Все гиганты ставят туда самое обычное железо, те же шеститонники например, и используют на них самый обычный софт. Всё потому что в кампусе от софта не требуется каких-либо извращений, пакеты по FIB гоняет — и ладно.
    2) Да, у FB и Google есть свои уникальные требования, и да, они не хотят зависеть от вендора. Их право. Многие другие крупные компании говорят вендору «мы купим у вас железа на 8-значный ценник, за это вы дадите нам такой-то и такой-то функционал», и обычно вендор этот функционал спешно кодит.

    >На самом же деле ничего уникального в идее перехода на собственное оборудование нет.
    Есть. Это очень дорого и сложно, лишь компании с очень сильным штатом разработчиков могут себе это позволить.

    >Скоро увидим Cisco ASR с dd-wrt
    Свят-свят… Он и с родным софтом глючит как каналья… Тысячник по крайней мере.
  • +2
    Я очень надеюсь и жду момента, когда сервера можно будет комплектовать не только sas-бэкплейнами, но и коммутационными бэкплейнами на 48 портов.

    Фактический управляемый коммутатор уже давно состоит из switch plane (весь из себя аппаратный и программируемый) и management plane (который весь из себя компьютер).

    Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства. А вот специализацию имеет смысл как раз в эти самые коммутирующие бэкплейны выпихивать. Количество возможностей, которое это открывает, трудно себе представить. Например, распределённый load ballancer может брать на себя часть нагрузки, а ту часть, которую не взял, коммутировать дальше по цепочке, к другим балансерам.

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

    SDN, само собой.
    • 0
      Виртуализаторы будут тоже очень счастливы, ибо коммутатор, наконец-таки, обзаведётся приличной операционкой и средой для выполнения какого-нибудь питона.

      да есть все это уже ) в той же NX-OS, к примеру
      • 0
        Приличной операционкой. apt-get install, всё такое. Какие-то подвижки в этом вопросе есть, но вот так вот с бухты-барахты адаптировать существующую ОС к нестандартному железу не получится, так что там либо гвоздями прибито, либо самодельное и уж очень простенькое.
        • 0
          >apt-get install, всё такое.
          Это как раз все тот же упомянутый в посте Cumulus, про который мы регулярно пишем.
          По архитектуре… тот же наш Eos 420 внутри имеет совершенно классический x86 Intel Atom C2758. Главная проблема — как раз в районе switch plane, где никто особо не горит желанием отдавать в открытое сообщество работу с матрицей. Так чисто любопытства ради стоит заглянуть на opennetlinux.org/ и посмотреть, что у них с новостями, что с доступностью SDK для работы с матрицами (подсказка: смотреть в FAQ).

          Сервер с коммутационным бэкплейном — идея красивая, конечно, но востребованность у нее сомнительная.
          • 0
            А почему Atom, а не парочка топовых зеонов с полутерабайтом памяти?
            • 0
              Потому что этого атома с избытком хватает на потребности ОС в том случае, если сетевой трафик не надо гонять на процессор и обратно и он бегает в пределах портов и ASIC'а.
              А парочка даже не самых топовых зеонов с четвертью терабайта памяти уже удваивает цену коммутатора (а это 48 х 10G). Пока не видно сколько-нибудь значимого количества клиентов, желающих оплачивать создание такого удовольствия. А главное, не очень понятно зачем оно такое: какие вы видите задачи, чтобы их в принципе было выгодно решать на дорогостоящей (по энергопотреблению и стоимости обработки трафика) универсальной архитектуре и нельзя было реализовать на NPU?
              • 0
                Потому что вы сейчас описываете решение задач, которые успешно решаются существующими решениями.

                Я бы не отказался видеть такой гибрид свитча с сервером в openstack'е в качестве сетевой ноды. Благодаря link-local уровню связности, load balancer может реагировать на даун сервера, который с ним связан прямым проводом, со скоростью среды и направлять трафик между бэкэндами с почти нулевыми накладными расходами (то есть в контексте 48 10-Гб портов — одна-две таких штук могла бы обслуживать практически неограниченный объём трафика, так как от быстрого процессора требовалось бы всего лишь обрабатывать 40-50 Mrps в пике, при этом реальный tcp держали бы бэкэнды, а не бедный балансер.
                • 0
                  Вы не учитываете, чем матрица связана с управляющей частью.
                  PCIe Gen2 x4, в лучшем случае и это именно интерфейс для программирования матрицы. При большом желании можно, наверное, обработку трафика тоже через него гонять, но это нетривиальная задача.
                  • 0
                    Это же исправимо, не? PCI-E x16.

                    Кроме того, если такой LB будет балансировать, то ему не надо будет получать весь фид в control plane. Он будет инспектировать заголовки flow, а дальше вся flow идти в режиме коммутации на нужный сервер.

                    Итого — в нормальном режиме, раздавая файлы по 125кб, и общем фиде в 240Гбит (240000 файлов в секунду) надо будет обслуживать жалкие 240к пакетов от заголовков flow. Что совсем не «жалкие», но добротный коннект по PCI и быстрые процы — вполне переварят. По 15к балансировок на ядро — очень даже гуманно.
                    • 0
                      Примерно так сделан FM10000 и RSA, но у него другая проблема — слабая коммутационная часть.
    • 0
      >>но и коммутационными бэкплейнами на 48 портов.

      Не нужно это, делать отдельный подвид ящиков сейчас нет смысла. Слишком специфична коммутационная часть.

      >> Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.

      Посмотрите на современный коммутатор — там уже стоят массовые PPC или Intel Atom, ось кидается на SSD, а за управление матрицей отвечает драйвер :)
      На тот же Cumulus Linux можно ставить любой сторонний софт.
      • 0
        В этом и проблема, в них ставят обычно унылое Г, а во многих применениях хочется иметь что-то приличное, с кучей ядер, кучей памяти и т.д.

        Короче, генерализация сетевого оборудования, как «переферия для сервера» может дать существенные изменения. А, главное, размыть network wall.
        • 0
          Таким балуется Pluribus. Пока без значительного успеха.
    • 0
      Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.

      Вы не поверите на сколько вы близки к истине. Juniper вообще изначально имеет на борту комп x86 с переработанной FreeBSD и не скрывает этого, а к компу присоединен DataPlane, который через шину (и драйвер) общается с ОС в обоих направлениях. CISCO тоже раньше ставила процы от моторолы, а на днях довелось разобрать (вроде 3750) коммутатор, так там intel и amd (я так понимаю от серии зависит) на MCU уже давно.
      • 0
        Juniper вообще изначально имеет на борту комп x86


        Зависит от железки. Кое где архитектура другая.
  • –1
    Давно пора
  • 0
    Было бы неплохо ссылку на оригинал с Wired.

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

Самое читаемое Разное