Мы создаём и развиваем сетевую инфраструктуру для всего Яндекса. Проектируем и строим сети внутри ЦОДов, связываем ЦОДы между собой, развиваем внешнюю связность и обеспечиваем доступность всей этой инфраструктуры проводным и беспроводным способом. Решение этих задач требует создания собственных сервисов и инструментов по управлению трафиком и флотом сетевых устройств, которыми занимается подразделение околосетевой разработки внутри NOC. Сокращенно NOCDEV.
<aside> <img src="/icons/car_gray.svg" alt="/icons/car_gray.svg" width="40px" /> Автоматизация сети Базис, с которого начинается запуск нового оборудования в работу и его дальнейшая эксплуатация. Мы пишем сервисы, которыми пользуются сетевые инженеры для автоматизации и валидации работ c десятком тысяч устройств.
</aside>
<aside> <img src="/icons/fire_gray.svg" alt="/icons/fire_gray.svg" width="40px" /> Файрволл Обеспечиваем безопасность сетевых доступов без риска обрушения всей инфраструктуры из-за деструктивных действий хакеров.
</aside>
<aside> <img src="/icons/fabric-swatch_gray.svg" alt="/icons/fabric-swatch_gray.svg" width="40px" /> L3 балансировка Позволяем остальным сервисам Яндекса внедрять технологию L3-балансировки за пару кликов.
</aside>
<aside> <img src="/icons/server_gray.svg" alt="/icons/server_gray.svg" width="40px" /> DNS Мы поддерживаем собственные решения наряду с DNS серверами, которые обслуживают десятки миллионов запросов в секунду как изнутри компании, так и извне.
</aside>
<aside> <img src="/icons/network_gray.svg" alt="/icons/network_gray.svg" width="40px" /> Несколько дата-центров связанных между собой
</aside>
<aside> <img src="/icons/server_gray.svg" alt="/icons/server_gray.svg" width="40px" /> Более 15 тысяч сетевых устройств (свитчей, роутеров, FPGA, ASIC)
</aside>
<aside> <img src="/icons/rocket_gray.svg" alt="/icons/rocket_gray.svg" width="40px" /> 16 терабит трафика в секунду
</aside>
<aside> <img src="/icons/database_gray.svg" alt="/icons/database_gray.svg" width="40px" /> Более тысячи железных серверов, на которых работают наши сервисы
</aside>
<aside> <img src="/icons/wifi_gray.svg" alt="/icons/wifi_gray.svg" width="40px" /> Тысячи точек доступа в офисах, на складах и даже в ЦОДах
</aside>
<aside> <img src="/icons/airplane_gray.svg" alt="/icons/airplane_gray.svg" width="40px" /> Надежность работы сети 24х7х365 на 99.99%
</aside>
Наши задачи можно условно классифицировать на следующие направления:
Одним из наших ключевых направлений является разработка системы для накопления и управления огромной базы знаний по десяткам тысяч устройств. Система обходит их, собирает необходимую информацию (MAC- и IP-адреса, фактический софт и его конфигурации) и предоставляет её вовне через API с возможностью динамического управления сетью. Мы называем этот сервис Inventory API. Это корневой компонент, он не только наши «глаза», но и «руки». Отсюда требования к его надёжности и производительности, ведь данных там приличное количество.
Мы всегда стремимся к автоматизации всех рутинных задач, например, предварительной настройке железа без участия. Для этого мы пишем и развиваем сервис автоматического ввода в эксплуатацию сетевых устройств: достаточно подключить устройство, а остальное происходит автоматически. Помимо разработки системы настройки, мы создаём систему для выполнения типовых задач на оборудовании. Сетевые инженеры создают сценарии для управления устройствами в нашей системе, а мы делаем так, чтобы эти сценарии выполнялись надёжно и прозрачно, а наша автоматика проверяла изменения на корректность так, чтобы ничего не сломать.
Одним из наших масштабных направлений является высокопроизводительная программная обработка трафика. Мы пишем декапсуляторы, файрволы, L3-балансировщики, туннелляторы, NAT64 и многие другие системы. Описанные компоненты должны быть максимально производительными и горизонтально масштабируемыми, ведь через них проходит трафик со скоростью 16 Тбит/с. Наши компоненты написаны на чистом C++ с нуля поверх DPDK-фреймворка, который обеспечивает нам требуемую гибкость и производительность.
Мало написать быстрые «перекладывалки» трафика, надо уметь ими управлять. Например, в случае файрвола что будет, если в силу человеческой или программной ошибки мы случайно раскатим правила, которые начнут отбрасывать весь или ощутимую часть трафика «на пол»? Чтобы такого избежать, мы разрабатываем специальный контур предварительной валидации файрвольных правил, задачей которого является сбор трафика с огромного числа машин (более 100000) и последующая эмуляция поведения файрвола перед моментом, когда правила поедут на конечные файрвольные фермы. Если в цифрах, то нужно за приемлемое время, скажем, за 5 минут проверить правила на более чем 100000 машин и прогнать по ним миллиарды записанных ранее пакетов.