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

В LinkedIn успешно протестировали коммутатор “Pigeon” первого поколения, который состоит из спроектированной на заказ аппаратной платформы, чипсета Tomahawk от Broadcom и сетевой ОС собственной разработки на базе Linux. Компания планирует использовать его в своем первом ЦОД – Infomart Datacenters в Орегоне. Коммутатор производительностью 3,2Tbps (32 порта по 100G) будет использоваться в качестве Leaf или Spine устройств в инфраструктуре LinkedIn.

linkedin-switch-pigeon
Коммутатор LinkedIn Pigeon (вид спереди)

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

История появления коммутатора LinkedIn

Напомним, что Google была одной из первых компаний-гигантов, спроектировавших собственный коммутатор. Несколько лет назад, Facebook также начал разработку сетевого оборудования. После создания Wedge – первой модели 40-гигабитного ToR-коммутатора Facebook, в конце прошлого года компания объявила о выпуске 100-гигабитной версии Wedge, производство которой планируется начать в ближайшем будущем.

Крупные компании из разряда Facebook, Google, Microsoft и Amazon, построившие инфраструктуры ЦОД беспрецедентных масштабов, пришли к тому, что решения, существующие на рынке, не отвечают их требованиям. И наиболее рациональное решение проблемы для этих гигантов – создать свою собственную платформу.

Теперь настала очередь LinkedIn.

Пользовательская база LinkedIn росла очень быстро (37 млн. участников в начале 2009 и 400 млн. – в третьем квартале прошлого года, согласно данным портала Statista), и 3 года назад компания столкнулась с проблемами, вызванными высоким уровнем задержек (latency) в работе приложений ЦОД. Задача оказалась серьезной, традиционные механизмы сбора информации не давали никаких результатов.

После долгой работы инженеры пришли к выводу, что проблема связана с таким понятием, как microburst – очень короткий период времени, когда количество принимаемых устройством данных становится больше, чем интерфейс способен отправить. Это вызывает переполнение буферов. Чем глубже инженеры разбирались, тем сложнее было найти простое и элегантное решение.

Тогда они решили пойти другим путем. Что если бы была возможность получить все телеметрические данные напрямую с чипсета? Производители коммутаторов, которые использовались в LinkedIn, не давали доступа к таким данным, так же, как и не давали прав на управление ASIC-ом. Единственным выходом было полагаться на вендоров и ждать, пока они смогут каким-либо образом решить проблему, что никак не входило в планы LinkedIn.

Тогда был составлен список других недочетов, с которыми компания сталкивается при использовании сетевого оборудования:

  • Ошибки в работе программного обеспечения, которые не могут быть решены в сжатые сроки;
  • Излишняя функциональность оборудования, из-за чего ошибок становилось еще больше;
  • Нехватка инструментов автоматизации на базе Linux, таких как Puppet, Chef, CFEngine;
  • Устаревшее ПО мониторинга и логирования;
  • Дороговизна лицензий при расширении и контрактов на поддержку.

После того, как был составлен этот список, «родился» и второй, состоящий из характеристик «идеального для компании коммутатора»:

  • Работа выбранного Merchant Silicon чипсета на любой аппаратной платформе;
  • Работа с тем же ПО и утилитами на коммутаторе, что и на серверах приложений (телеметрия, логирование, мониторинг и т.д);
  • Возможность быстрого реагирования на новые требования;
  • Нацеленность на принципы DevOps, т.е. «коммутаторы должны в обслуживании быть аналогичны серверам и иметь унифицированную платформу»;
  • Неограниченные возможности программирования;
  • Скорость разработки нового функционала;
  • Более короткие циклы обновления;
  • Контроль стоимости аппаратных и программных частей.

Когда инженеры увидели какой коммутатор им нужен, проблема с буфером отошла на второй план. Идея о программируемом сетевом оборудовании открывала мир возможностей и путь к построению программно-определяемого ЦОД (Software Defined Datacenter, SDDC).

Так появился проект Falco, целью которого стало создание собственной платформы коммутации. Используя принципы, перечисленные выше, компания разработала базовую архитектуру, которая соответствовала требованиям LinkedIn.

linkedin-switch-pigeon-architecture
Архитектура коммутатора LinkedIn. Источник – блог LinkedIn

В основе уровня приложений архитектуры лежат компоненты, которые уже используются в инфраструктуре компании:

  • LinkedIn Tools – набор утилит для автоматизации процессов конфигурации инфраструктуры;
  • Auto-Alerts – средство мониторинга и оповещения;
  • Kafka client – распределённый программный event-брокер, используемый для работы с метриками;
  • Telemetry client – интерфейс к SDK чипсета для получения статистики буфера.

Компания не собирается останавливать работу над проектом. В планах – сотрудничество с производителями платформ, поддерживающих ONIE и предоставляющих доступ к программированию чипсета. Также, в 2016 году планируется добавление поддержки Switch Abstraction Interface (SAI), о котором мы расскажем в ближайших статьях.

SDNBLOGGER
SDNBLOGGER - команда SDNBLOG, которая занимается поиском наиболее интересных новостей из мира SDN и NFV, а также публикует статьи по тематике. В команду входят ведущие российские специалисты в области технологий SDN и NFV.

НЕТ КОММЕНТАРИЕВ

ОСТАВЬТЕ КОММЕНТАРИЙ