Тема полезных приёмов работы в терминале Linux неисчерпаема. Казалось бы — всё устроено очень просто: приглашение оболочки, да введённые с клавиатуры команды. Однако, в этой простоте кроется бездна неочевидных, но полезных возможностей. Именно поэтому мы регулярно публикуем материалы, посвящённые особенностям работы в командной строке Linux. В частности, сегодня это будет перевод статьи, автор которой увлечён экономией времени через повышение продуктивности труда.



Если вас интересует работа в командной строке Linux — вот некоторые из наших материалов на эту тему:

• [ +114 ] Самые полезные приёмы работы в командной строке Linux
  
• [ +70 ] 10 приёмов работы в терминале Linux, о которых мало кто знает
  
• [+65 ] Удивительно полезный инструмент: lsof
  
• [ +32 ] Linux: перенаправление
  
• [ +29 ] PDF-версия статей про Bash-скрипты
  

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Когда стоит вопрос выбора между проприетарным и открытым программным обеспечением, часто в пользу последнего приводят следующий аргумент: при необходимости можно изменить исходники под нужды своего проекта, или исправить ошибку прямо сейчас, а не дожидаясь месяцами реакции вендора. Зачастую это соображение является оторванным от практики — куда проще исправить SQL запрос, чем оптимизировать SQL-планировщик, или поменять проблемное оборудование вместо того, чтобы искать и исправлять ошибку в драйвере. Тем не менее, иногда именно открытость кода позволяет избежать потенциальных убытков и перерасхода вычислительных ресурсов. Хочу рассказать об одном из таких кейсов, случившемся за время моей работы в Advanced Hosting

Сегодня хочу рассказать о концепции, которая в ближайшие несколько лет в корне изменит дизайны сетей связи и телекомуникационных услуг — о виртуализации сетевых функций, Network Functions Virtualization.

В отличие от повсеместно распространённой виртуализации приложений, сетевые функции перенести в облако гораздо сложнее, а некоторые из них вообще невозможно. Я расскажу о задачах и принципах NFV, об истории этой инициативы и её нынешнем статусе, об ограничениях и недостатках этого подхода, поделюсь своими мыслями о том, какие задачи с её помощью решаемы, а какие — принципиально нет.

Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.

Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.

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

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.

---

Зачем вообще может понадобиться инжиниринг трафика?

Данная статья написана так сказать по заявкам слушателей нашей радиостанции. При настройке Option C на JunOS у многих возникает один и тот же вопрос: почему ничего не работает хотя все вроде бы правильно? На JunOS все не так тривиально, как на Cisco и проблем может быть несколько. Перейдем непосредственно к сути: симптомы такие — вы настроили на ASBR BGP-LU сессию для организации Opt.C стыка на оборудовании Juniper (и естественно VPNv4 сессию между рефлекторами, но она тут не причем), но пинги между лупбеками PE маршрутизаторов различных автономных систем есть, а вот L3VPN не работает. Давайте разбираться, почему это происходит и как с этим бороться.

Хочу описать схему с DMVPN, построенную у нас в организации, позволяющую использовать неограниченное число каналов связи на удалённой точке через Public Internet наряду с каналом IPVPN от одного из нескольких провайдеров.

Что есть: построенная схема DMVPN с (в основном) двумя каналами связи. Основной — IPVPN (с гарантированной скоростью) от одного из провайдеров, резервный — Public Internet (любой, возможно даже 3G\LTE роутер) от другого провайдера.

Схема того, что было:

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

Добрый день!

Недавно прочитал очень интересную статью про обработку 50 гигабит/с на сервере и вспомнил, что у меня в черновиках лежит статья про то, как мы год назад разрабатывали систему мониторинга видео-потоков с общим объёмом трафика до 100 Гбит/с. Ещё раз “вычитал” её и решил представить на суд разработчиков. Статья больше посвящена анализу протоколов и поиску архитектурного решения, нежели тюнингу всевозможных подсистем linux’а, потому что мы пошли по пути распределения нагрузки между сервером и сетевыми пробниками, которые подключаются к транспортным потокам 10 Gigabit Ethernet.



Если интересно, как мы смогли измерить характеристики сетевых потоков от 55 тысяч видео-камер, прошу под кат.

Всем привет! Я хочу поделиться анализом существующих технологий Intel, которые позволяют максимально быстро передать трафик из физической карты на виртуальную машину. В принципе, все способы опробованы в реальности на картах Intel XL710, поэтому я так же скажу об их плюсах и минусах. И поскольку наша компания занимается в том числе разработкой виртуального свитча, все это с точки зрения виртуального свитча.

Intel SR-IOV

Не совсем технология от Intel, но пощупать удалось только их реализацию. Вкратце, физический адаптер (PF) делится на несколько виртуальных (VF). Трафик внутри одного vlan по умолчанию не выходит за границы PF, и обеспечивает наиболее минимальные задержки по сравнению с виртуальными адаптерами на софтовых бриджах.


С помощью использования Intel FlowDirector в принципе можно изменить поведение и указать правила по которым трафик должен ходить между VF или наружу из PF. Также можно сделать ручное распределение трафика по RX очередям или хардварный дроп трафика сразу при входе на карту. Поддержка конфигурации flow есть в драйверах, но отдельного api конкретно для Flow Director я не нашел. Кто хочет поиграться — можно покопаться в исходниках ethtool, либо использовать Intel DPDK, в нем API реализован, но карта отцепляется от kernel драйвера со всеми вытекающими.

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

Плюсы: работа как в VMWare, так и KVM. Везде быстрее софтовых бриджей как по задержкам, так и пропусной способности. И CPU не жрет.

Минусы: виртуальный свитч в данном кейсе — нужно превращать в реальный на отдельном железе, куда втыкаются PF от сервера с виртуальными машинами.
И 64 VF на один PF сейчас достаточно мало.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Мой самый первый пост, который я три года назад написал на Хабр, был посвящен 10G Ethernet и 10G сетевым картам Intel, что, в принципе, не случайно, ведь сетевые технологии – это моя профессия. Далее посты на данную тему почти не появлялись в блоге Intel – как говорится, не было повода. И вот теперь он появился, и вполне весомый. Ведь выход нового поколения сетевых карт Intel на контроллере X/XL710 принес с собой не только улучшение характеристик и новые возможности, но и появление принципиально нового для компании продукта – 40G Ethernet сетевых карт для серверов. Самое время поговорить о текущей ситуации в области 40-гигабитности.

В решениях, направленных на виртуализацию реальных сетевых функций, основным фактором является способность обеспечить предсказуемую и гарантированную производительность и пропускную способность для трафика заказчика. Во многих проектах, предназначенных для проверки концепции, уделялось значительное внимание повышению пропускной способности сети, но величина задержек является не менее важным показателем работы сетей (а в ряде случаев — гораздо более важным). В этой статье описывается тестовая среда в лабораториях BT Adastral Park на основе архитектуры Intel Open Network Platform. Эта тестовая среда разработана для оценки производительности локального оборудования заказчиков с виртуализацией.

Недавно в нашем блоге появилась статья о NUMA-системах, и я хотел бы продолжить тему, поделившись своим опытом работы в Linux. Сегодня я расскажу о том, что бывает, если неправильно использовать память в NUMA и как диагностировать такую проблему с помощью счётчиков производительности.

Компьютеры, даже персональные, становятся все сложнее. Не так уж давно в гудящем на столе ящике все было просто — чем больше частота, тем больше производительность. Теперь же системы стали многоядерными, многопроцессорными, в них появились специализированные ускорители, компьютеры все чаще объединяются в кластеры.
Зачем? Как во всем этом многообразии разобраться?
Что значит SIMD, SMP, GPGPU и другие страшные слова, которые встречаются все чаще?
Каковы границы применимости существующих технологий повышения производительности?

Введение

Откуда такие сложности?

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

Я думаю, многие уже успели заглянуть и прочитать эту статью на английском в моем блоге, но для тех кому все таки комфортней читать на родном языке, нежели иностранном (как сказали бы на dirty.ru – на анти-монгольском), я перевожу очередную свою статью.

Вы уже наверняка знаете, что NUMA это неравномерный доступ к памяти. В настоящий момент эта технология представлена в процессорах Intel Nehalem и AMD Opteron. Честно говоря, я, как практикующий по большей части сетевик, всегда был уверен, что все процессоры равномерно борются за доступ к памяти между собой, однако в случае с NUMA процессорами мое представление сильно устарело.

NUMA (Non-Uniform Memory Access — «Неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — технология совсем не новая. Я бы даже сказала, что совсем старая. То есть, в терминах музыкальных инструментов, это уже даже не баян, а, скорее, варган.
Но, несмотря на это, толковых статей, объясняющих, что это, а главное, как с этим эффективно работать, нет. Данный пост, исправляющий эту ситуацию, предназначен прежде всего для тех, кто ничего не знает про NUMA, но также содержит кое-что интересное и для знатоков-NUMизматов, а главное, он облегчает жизнь мне, инженеру Intel, так как отныне всех интересующихся NUMA русскоязычных разработчиков буду отсылать к нему.

В этой статье описывается настройка ограничения скорости входящего трафика для интерфейса Data Plane Development Kit (DPDK) в Open vSwitch (OVS) с DPDK. Эта статья предназначена для сетевых администраторов, которые могут использовать ограничение скорости Open vSwitch, чтобы обеспечить гарантированную скорость приема для портов DPDK на развернутых серверах Open vSwitch. Эта статья дополняет статью Настройка и использование качества обслуживания для Open vSwitch* с DPDK, поскольку ограничение скорости и качество обслуживания действуют соответственно в трактах приема и передачи, используя уникальные команды API для настройки и работы.

Пакет Data Plane Development Kit (DPDK) предоставляет высокопроизводительные библиотеки обработки пакетов и драйверы пользовательского пространства. Начиная с Open vSwitch (OVS) версии 2.4 мы имеем возможность использовать оптимизированный с помощью DPDK путь vHost в OVS. Поддержка DPDK была доступна OVS с версии 2.2.

Использование DPDK в OVS дает существенные преимущества с точки зрения производительности. Как и в других приложениях, использующих DPDK, резко повышается сетевая пропускная способность (количество передаваемых сетевых пакетов) при существенном снижении задержек. Кроме того, с помощью библиотек обработки пакетов DPDK была оптимизирована производительность некоторых наиболее важных сегментов OVS.

В этом документе мы рассмотрим настройку OVS с DPDK для использования между виртуальными машинами. Каждый порт будет подключен к отдельной виртуальной машине. Затем мы запустим простой тест пропускной способности iperf3 и сравним производительность с работой конфигурации OVS без DPDK, чтобы оценить, какие преимущества мы получаем в OVS с DPDK.