Пару лет назад я завершил проект миграции в сети одного из наших клиентов, задача заключалась в смене платформы, которая осуществляет распределение нагрузки между серверами. Схема предоставления сервисов этого клиента эволюционировала в течении почти 10-ти лет вместе с новыми разработками в индустрии ЦОД, поэтому «придирчивый», в хорошем смысле этого слова, клиент ожидал решения, которое удовлетворяло бы не только требованиям отказоустойчивости сетевого оборудования, балансировщиков нагрузки и серверов, но и обладало бы такими свойствами как масштабируемость, гибкость, мобильность и простота. В этой статье я постараюсь последовательно, от простого к сложному, изложить основные примеры использования балансрровщиков нагрузки без привязки к производителю, их особенности и методы сопряжения с сетью придачи данных.

Даже в хорошей, с точки зрения дизайна, сети время от времени приходится проводить работы по актуализации конфигураций тех или иных сущностей. Среди наиболее веских и ожидаемых причин подобной активности можно отметить миграции для согласования физической и логической плоскостей, развитие сети в рамках процесса технологической эволюции, гармонизация архитектур присоединяемых сегментов и решение проблем роста. На самом деле, жизненный цикл сети, почти всегда представляет из себя изменения с тем или иным уровнем рисков и панируемого влияния на сервис, в оценке которого нельзя не учитывать человеческий фактор. Хотя, будет вполне уместным обобщить это описание на большинство областей человеческой деятельности, функционирование коммуникационных сетей обладает некоторыми особенностями, которые заслуживают понимания, или хотя бы внимания, — элементы коммуникационных сетей находятся в плотной связи, тесно взаимодействуют и оказывают не только прямое, но и косвенное воздействие друг на друга. Поэтому, грамотная стратегия проводимых работ станет только продуктивнее будучи подкреплённой механизмами, которые снижают, насколько это возможно, вероятность появления человеческих ошибок. В очередной статье цикла «Зачем сетевым инженерам программирование» я расскажу о вариантах применения автоматизации в одной задаче подобного рода.

Использование программирования в сетевом деле уже стало трендом, поэтому в продолжении статьи Зачем сетевым инженерам программирование я начинаю серию небольших заметок про автоматизацию решения тех или иных практических задач. Чтобы развеять ореол сложности вокруг этой темы, будут опубликованы некоторые примеры и кейсы, в основном с использованием Python, и даны ссылки на более глубокий материал и техническую документацию. Вступительная статья этого цикла ниже.

В этой статье я расскажу — что такое EVPN/VXLAN и почему особенности этой технологии кажутся мне привлекательными для применения в ЦОД. Я не буду глубоко погружать вас в технические детали, а остановлюсь на них лишь в той мере, в которой это необходимо для знакомства с технологией. Почти все чего я буду касаться в этой статье так или иначе связанно с передачей трафика второго уровня OSI между устройствами в одном широковещательном домене. Есть множество задач прикладного характера, которые можно комфортно решить, имея такую возможность, одним из наиболее знакомых примеров такой задачи является миграция виртуальных машин в рамках одного или нескольких ЦОД. И если некоторое время назад разговор об этом неминуемо поворачивал в плоскость обсуждения проблем и неудобств общего широковещательного домена, сейчас, напротив, мы можем размышлять о решении этой задачи с точки зрения новых возможностей, перспектив и удобства.

Интересно обменяться мнениями и опытом применения языков программирования в решении задач сетевого инженера, если вы используете какие-то методы и подходы автоматизации, напишите об этом в комментариях, а я расскажу о некоторых своих наработках в этом направлении.

Вчера общался со своим старым приятелем, он рассказал о завершении проекта модернизации большого ЦОД — сетевой дизайн с чистого листа, Leaf/Spine, TOR, новое оборудование, отказоустойчивость, все красиво и свежо. Мы знакомы еще с тех пор когда 40Gbit/s на слот казалось чем-то запредельным, собственно наши профессиональные дороги плотно сошлись на фоне изучения внутренней переподписки, архитектуры и особенностей передачи трафика в линейных картах одного известного производителя. Поэтому, когда приятель спросил: “А знаешь почему я тебе звоню?”, я, нисколько не задумываясь, ответил — «Что, опять дропы?»

Разглядеть то что находится на верху лестницы находясь где-то в ее середине настолько же сложно как понять какие тенденции индустрии телекоммуникаций прочно укрепятся и станут фундаментом будущих разработок, а какие исчезнут без следа. Не так давно, в рамках дизайна Cloud-Grade Networking, Juniper Networks анонсировал появление нового механизма виртуализации своих продуктов, а также представил концепцию универсального шасси для routing и switching применений. Новости важны в плане практического применения и интересны как повод погадать о будущем.

В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в MPLS домене, идея была в том чтобы показать уникальные требования к аппаратной реализации чипа, которые позволяют достигнуть успеха, в том или ином случае. Вторая часть будет посвящена рассказу об относительно свежем драфте [Multi-path Label Switched Paths Signaled Using RSVP-TE] от Kireeti Kompella, и описанию применения его реализации от Juniper к решению некоторых задач.

Технологии MPLS сегодня стали де-факто стандартом построения сетей операторов связи. Некоторые участники начальных разработок утверждают, что работа была направлена на получение протокола с фиксированной длинной заголовка чтобы упростить процесс принятия решений маршрутизации, однако революционных изменений в этом смысле не произошло, а после после появления аппаратных реализаций коммутационных чипов проблема производительности отошла на второй план. Зато по мере того как стандарт обрастал мышцами, становилось понятно, что применение нескольких меток, названных впоследствии стеком, позволяет взглянуть на MPLS как на технологию с унифицированными методами предоставления и обеспечения сервисов. Так, метки в стеке условно поделили на сервисные и транспортные. Для больших сетей этого оказалось недостаточно и вскоре появилась собственная иерархия транспортных меток. Транзитные маршрутизаторы в общем не обязаны понимать какой именно сервис они передают, их задача в самом общем смысле ограничивается работой с верхней меткой своей иерархии, а что там находится внутри стека совершенно не их забота. Такой подход позволяет транзитным маршруитзаторам передавать трафик сотен тысяч и даже миллионов потоков разных сервисов.

Казалось бы, чего еще желать… правило «разделяй и властвуй» работает безотказно, но вот эффективно разделять как раз не очень то получалось, в том смысле, что трафик хочется балансировать как можно равномернее в рамках ограниченного количества каналов связи силами неторопливых, с точки зрения изменений, аппаратных решений. В статье вы найдете некоторые аспекты разных методов решения этой задачи.

Широко известной новостью в узких кругах стало появление в релизе Junos 16.1 механизмов расширенной очередизации на фиксированных 10G портах платформ MX80/MX104.

Как это иногда случается, техническая документация по новым возможностям выходит с некоторой задержкой, даже сейчас разделы посвященные этой теме оставляют ощущение недосказанности. К счастью, коллеги из московского представительства Juniper на конференции Juniper Networks Summit помогли найти ответы, за что им большое спасибо.