Author: weril

• Статья по использованию screen
• tmux – terminal multiplexer
• (screen, tmux) У screen есть мощные альтернативы (напр. tmux, Byobu), но их нужно устанавливать, а screen часто бай-дефолт установлен в системе (есть даже на MacOS!). Почему стоит использовать tmux вместо screen:
  • screen deprecated, по крайней мере для RHEL-based систем.

Интересный производитель сетевых устройств из USA. Из названия прослеживается ключевая цель – создание девайсов для подключения конечных абонентов (последней линии). В первую очередь закрывают потребности киношников/блогеров – девайсы имеют усиленный формат, просты в обращении. Общее про решаемые задачи/протоколы в отдельной статье.

Читать дальше

• Очень много презентаций о VPP на сайте fd.io
  • • Разобрал только эту “How to Push Extreme Limits of Performance and Scale with Vector Packet Processing Technology”
• Netgate TNSR – один из известных комерческих проектов, использующих VPP
• Есть даже аппаратные ускорения VPP на базе спец.

• Мы юзаем azure devops/tfs
• МТС юзает Allure TestOps для автоматизации функциональных сценариев, API и здесь же автоматизация методик нагрузочного
• Мвидео и сбер юзают Zyphir Scale (плагин для jira), интегрируется с jenkins, запускаются автотесты с очтетами
• Мвидео где-то юзает и TestRail

zephyr scale

A scalable, performant test management solution inside Jira with advanced test planning, reporting, and reusability features

allure testops

Хорошая система тест кейсов (как функциональные, так и нагрузочные) с отчетами, которая легко интегрируется

• • в CI (gitlab, jenkins, tfs/azure, etc)
  • в код

 

Читать дальше

• Эта статья под распил к конкретные, тут заметки именно
• Многие инструменты и практики devops на собеседованиях/в требованиях сейчас спрашивают и у сетевых инженеров и у performance инженеров и у программистов; по сути это универсальные знания, которыми нужно обладать
• Кто то SRE выносит отдельно от devops, кто то его считает подвидом devops
• По практике работы SRE с мониторингом в отдельной статье
• Многое более детально описано в отдельных статьях – docker, k8s, terraform, best practice (microservice)
• Часть взято из практики
• Часть из феникс-проекта
• Часть с сайта https://easyoffer.ru/rating/devops

SD-WAN

• Cisco SD-WAN
• VMware SD-WAN
• Kaspersky SD-WAN
• Bi.zone SD-WAN

Материалы:

• Преза/datasheet
• Сайт

Заявляют функционал сопоставимый международным игрокам:

• Платформа построена на базе технологий компании Brain4Net (ранее стартап РТК проданный Касперскому)
• Основной кейс – защита филлиальной сети для крупных заказчиков или интеграторов (multi-tenenacy контроллерр)
• Поддержка любых каналов для spoke (4G, MPLS, Ethernet, PPPoE, L2) с резервированием
• Из преимуществов решения сам касперский выделяет
  • экспертиза касперского для баз (TI, сигнатур и проч)
  • самих решений SD-WAN немного на рынке, основные его преимущества: ZTP, динамическое переключание каналов
  • потенциально реализуемость SASE одним вендором
• Компоненты закрытые, не opensource
  • Основной компонент – openflow SDN контроллер, соответствует openflow версии 1.3-1.4 (рабочая версия для реальных сетей; используют так же extension к протоколу, опубликованные в RFC), реализует разную логику топологическую, реализует сервисные примитивы p2p, p2m, m2m L2, L3VPN, 8 layers QoS централизованно управляемая модель, ECMP (weighted, equal cost), traffic engineering, измерение параметров пути с «маршрутизацией» на основе этих параметров
  • Компонент2: NFV платформа как средство деплоя/управления сетью на основе OpenStack (может работать как с нативным OpenStack, так и с собственным контроллером Brain4net) – деплой сетевых функций в виде виртуальных машин, организация связи между ними и в external
  • Компонент3: высокопроизводительный DPDK switch OS на основе OpenFlow 1.3 (не на базе Open vSwitch), деплоятся на whitebox (в том числе high-performance chip trident, trident2+, tomohawk, tomohawk2)
• На базе этих компонентов реализуется как SDN, так и SD-WAN с L2 overlay backbone на базе контроллера (объединение CPE виртуальных и аппаратных, CPE реализован на базе OpenVswitch) с реализацией логики SD-WAN на базе стандарта (multipathing, routing, измерение параметров overlay туннелей с изменение маршрутизации на основе изменений параметров, TE).

Решил сделать разбор (в целом неплохого, но по многим вопросам спорного) видео о прошлом, настоящем и будущем компьютерных сетей от исследователей open networking foundation – The network as a programmable platform.

По мнению авторов видео недостатки старых подходов:

• Ненадежный проприетарный софт с десятками миллионами строк кода – насчет ненадежности крайне спорно, особенно когда речь идет о магистральном оборудовании и оборудовании ЦОД
• Огромные мейнфреймы как для обработки сетевого трафика (Cisco ASR/CRS), так и для обработки вычислений (IBM Z) – лучше масштабироваться горизонтально, согласен, но многоюнитовые шасси как выпускались, так и продолжают (и в ДЦ сегменте, хотя безусловно в меньшем объеме), в том числе из-за высокопроизводительного бекплайна между картами
• Сложно или невозможно что-то улучшить без привлечения сетевого вендора – многим ли нужно программировать ПЛИС самостоятельно или мониторить микроберсты, тем кому нужно это узкий рынок
• (как вывод) стагнация – cisco и другие вендоры сильно не согласятся и будут во многом правы – они решали и решают задачи, несмотря на постоянный рост объемов трафика

• Merchant silicon – имеется ввиду, что чипы для устройств не разрабатывает каждый сетевой вендор, они продаются на рынке (broadcom, marvel, ibm, qualcom, intel..).