Juniper Node Slicing и Universal Chassis

Разглядеть то что находится на верху лестницы находясь где-то в ее середине настолько же сложно как понять какие тенденции индустрии телекоммуникаций прочно укрепятся и станут фундаментом будущих разработок, а какие исчезнут без следа. Не так давно, в рамках дизайна Cloud-Grade Networking, Juniper Networks анонсировал появление нового механизма виртуализации своих продуктов, а также представил концепцию универсального шасси для routing и switching применений. Новости важны в плане практического применения и интересны как повод погадать о будущем.
Сначала маркетологи, а потом и инженеры стали называть современные маршрутизаторы мультисервисными. Ведь прекрасно когда одно шасси может решать задачи маршрутизации на пиринговых стыках, терминировать абонентов ШПД, передавать транзитный MPLS трафик, вытягивать пакеты из оверлея ЦОД и даже делать трансляцию адресов и протоколов. Многофункциональность и снижение единиц оборудования кажется обоснованной и людям, в костюмах, которые хорошо умеют считать Capex/Opex, и людям, которые рассчитывают место в стойке и требуемую мощность ИБП, по ночам смотрят на алерты мониторинга, занимаются инвентаризацией, настраивают или обслуживают это оборудование, потому-что с одной сущностью управляться легче чем с десятью. Все бы хорошо, но по мере увеличения количества функций, между ними появляются внутренние противоречия. Представьте себе мульти-прибор, который стирает, готовит обед и хранит зимние шины, из-за неидеального ПО обед может получится не вкусный, потому-что в ингредиенты случайно попало немного стирального порошка, а шины могут деформироваться из-за близкого расположения духовки. В своей практике я работал с клиентами, маршрутизаторы, которых на протяжении жизненного цикла превратились в монолит. Разобрать его уже не получается, потому-что «это наше все», а эксплуатировать становится все сложнее, потому-что одна функция, опять таки из-за неидеальности ПО, мешает выполнению другой.
Наши коллеги по IT давно решили для себя похожие проблемы — администраторы серверов все плотнее используют виртуализацию и контейнеры, а разработчики активно декомпозируют сущности и пишут микро-сервисы. Сетевые инженеры до недавнего времени могли позволить себе только виртуализацию, как сказал один мой друг из Одессы — виртуализацию для нищих, в виде отдельных таблиц маршрутизации, контекстов управления или логических маршрутизаторов. Это добавляет стабильности и удобства так как разделяет задачи хотя бы на уровне процессов сетевой операционной системы, но не решает проблему монолитности глобально. И вот наконец Donyel Jones-Williams Director of Service Provider Product Marketing Management из Juniper Networks заявил следующее — We are doing the same thing for routers that hypervisors did for servers. На мой взгляд, получилось даже интереснее, потому-что Junos Node Slicing, так называется система виртуализации от Juniper Networks, подразумевает запуск экземпляров операционной системы не на RE, а на отдельных серверах, вот как это выглядит.

Как видно из иллюстрации, GNF (guest network function) — экземпляр Junos, запускается в виде отдельной виртуальной машины и монопольно получает в распоряжение набор ресурсов помещенных в слоты FPC. Каждый GNF вместе с набором FPC видится снаружи и функционирует как совершено отдельный маршрутизатор, при этом трафик между GNF можно передавать по фабрике. Такой подход исключает внутренние противоречия между функциям маршрутизатора, повышает стабильность системы в целом, а кроме этого обладает «природной» способностью разделить административные домены управления между подразделениями организации. Позвольте еще одну иллюстрацию, уж очень красиво стали их рисовать.

Скорое появление универсального шасси, где могут быть использованы интерфейсные карты от PTX10008, PTX10016, QFX10008, QFX10016 и MX, а именно об этом сообщается в пресс-релизе Juniper Networks, вызывает только один вопрос — А что, так можно было? У Juniper уже есть некоторые наработки в области унификации, так например некоторые концентраторы линейных карт от MX240-MX960 уже давно можно использовать на топовых MX2010 и MX2020. Нынешняя задача выглядит более серьезной, так как в одном шасси нужно объединить карты, спроектированные с учетом особенностей работы во всех сегментах сети — ЦОД, ядро, граница. Как это сделано, пока не сообщается, но по словам Donyel Jones-Williams новая платформа уже находится в тестовой эксплуатации в сетях крупных заказчиков.
Так какое же будущее пытается приблизить Juniper Networks? Производитель концентрируется не только на аппаратуре, а смешает акценты в сторону управления и гибкости эксплуатации. По разным оценкам, стоимость конечного продукта только на 40% определяется аппаратной начинкой, примерно столько же стоит разработка программного обеспечения, средств интеграции и автоматизации. Посмотрим что из этого получится и, по-возможности, поучаствуем в развитии индустрии, ведь никто не знает куда выведет лестница, как сказал Док Браун — будущее еще не написано.
Пресс-релиз и документацию на Junos Node Slicing можно посмотреть тут:
→ Juniper Networks Unveils Cloud Grade Networking to Accelerate Agility and Innovation in the Cloud Era→ Junos Node Slicing Feature Guide