Из серии "Смотрите что нашел!"

Low latency tuning guide - сборник техник по оптимизации системы для минимизации задержек.

Внутри как привычные подходы вроде изоляции ядер и отключения гиперпоточности, так и совсем для меня новые:

- сокращение прерываний таймера планировщика через nohz_full, что будет снижать накладные расходы на context swithing.
- закрепление страниц в RAM с помощью mlockall(MCL_CURRENT | MCL_FUTURE), чтобы избежать их выгрузки на диск.

Особую ценность добавляет обилие ссылок для более глубокого погружения в предмет.

Упражнение: задавать себе вопросы из разряда: "Для low latency советуют SCHED_RR и SCHED_FIFO, а что если важнее пропускная способность? Как бы я изменил подход? Почему?"

#kernel #tuning #low_latency

Я до сих по не перебрался ни на какую блог-платформу, а телеграф не прожевал столько контента (я поражен).
Пришлось писать на хабре, извините 😩
В общем, идите на ближайший рынок - покупайте там коммутаторы китайские, ставьте туда линукс и запускайте FRR. Так победим импортозамещение.
А про БАЗУ FRR-а можно почитать тут
https://habr.com/ru/articles/884824/

Телеграм на этой неделе прямо радует обилием интересностей, куда же без IPv6? Никуда.

Наткнулся на интересный доклад по миграции с IPv4 на IPv6.

До этого уже писал про переход внутри гугла, а тут вот FB. Идёт 2025 год и только компании в духе Google или FB переходят на IPv6.

да да, Яндекс тоже

Дословно "Our edge network infrastructure is sufficiently large that we have run into scaling problems with IPv4 addressing."
Короче у ребят проблема пока что на границе, но внутри также ходит IPv4, и ещё походит думаю не один год...

А доклад любопытный, и оформление и задача и решение.

https://storage.googleapis.com/site-media-prod/meetings/NANOG92/5237/20241022_Kirkland_Removing_Ipv4_Infrastructure_v1.pdf

https://youtu.be/IKYw7JlyAQQ?si=zyPRkzYaR0rJ0FIR

За наводку спасибо ребятам из чата по ipv6 - @version6

Быстрая ремарка по свежим впечатлениям: дочитал Марсианина Энди Вейера, пишу об этом только по двум причинам.
Первая, несколько раз был упомянут hexedit, Linux, было минимум два патча один в ручном наборе, а второй на 20Мбайт обновлений марсохода и присутствует типичный системный администратор-тыжпрограммист, который пересылает почту и решает компьютерные проблемы одновременно с управлением атомным реактором.
Вторая причина, это множество конфликтов, если оставить за бортом главный - человек против природы и обстоятельств, то остальные прямо эталонные, стереотипные, фоном к основному: винтик и система, начальник и подчинённый, инженер и менеджер, "ботаники" (айтишники, учёные) и остальные, части системы между собой. Всё считывается моментально, всё на поверхности и очень-очень узнаваемо, что даже как-то грустно что оно везде так и у всех.
В целом если видели фильм, книга ничего нового не принесёт, я не увидел никаких подтекстов и каких-то глубинных смыслов. Помимо стереотипных конфликтов, изобилует и другими стереотипами, но это не раздражает. Читается легко и быстро, основной мотив: человек в обстоятельствах, жизнь в её наивысшем проявлении - в борьбе за выживание, чем-то напоминает философию Морского волка Джека Лондона.

Суть произведения одной картинкой.

Итак, приглашаю всех на сетевой митап Patchcord connect в Волгограде, Субботу 12 апреля в 14:00, место в самом центре - ЛОФТ1890, ул. 10-й Дивизии НКВД 5A, рассчитываем на 4 часа. Планируется четыре доклада, которые я предложил сделать своим друзьям, не сильно ограничивая их в выборе тем, попозже про них тоже объявлю. Сам я расскажу про НСДИ и как я его мониторил с помощью Ripe Atlas последние 3 года. Я сделал бот для регистрации, общения и вопросов @PatchcordConnectBot, который позволит не забыть сходить на встречу, а мне позволит более точно понимать количество желающих прийти, хотя на регистрации я не настаиваю. Я, конечно, ещё много раз напомню про мероприятие, постараюсь это делать ненавязчиво. Вопросы можно задавать мне @UrgentPirate, всем буду рад кто придёт, всех с нетерпением жду.

Я интерпретирую это как почти 30%, как минимум, приступили к процессу импортозамещения, если до этого не использовали отечественные решения. Из того что я вижу вокруг, процесс (реальный процесс), начался с середины прошлого, начала этого года, для тех кого не подгоняли обстоятельства или государство. Кто этим не занимался до 22 года, для них он стал годом принятия и осознания, 23 год - окончательное принятие и бюджетирование, 24 год - тесты, возможно что-то стало появляться, ещё раз подбиваются все бюджеты, 25 год - конец трёхгодичного цикла поддержки, того оборудования что было и непосредственное внедрение новых решений. При отсутствии изменений, я думаю, дальше будет больше, причём значительно и за короткий период.

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

Смотрю на облачное решение Касперского, а они хостятся не в России - "Сервере администрирования Kaspersky Security Center Cloud Console по адресу *.ksc.kaspersky.com":

host ksc.kaspersky.com a.res-nsdi.ru
Using domain server:
Name: a.res-nsdi.ru
Address: 195.208.4.1#53
Aliases:
ksc.kaspersky.com has address 213.250.132.250

в CDN Huawei в Стамбуле. Даже если там только часть, то всё равно в этом что-то есть, многоуровнево.

Если существует предопределённая возможность отослать данные за пределы системы, они будут отосланы. В случае с Nextcloud после обновления и изменения настройки по-умолчанию. Поведение по-умолчанию это одна из тех самых сложностей, которые стоит всегда принимать в расчёт и переопределять в явном виде. И конечно, второй эшелон защиты тоже можно построить, а может и третий, если это действительно важно.

nftables вот-вот доберётся до kube-proxy с версии Kubernetes 1.33. В Linux дистрибутивах iptables заменили на nftables несколько лет назад, в Debian 10 и Red Hat 9, например.

dnsclay для управления записями в зонах через DNS UPDATE RFC 2136 для многих DNS провайдеров через libdns, включая, например Godaddy, Cloudflare, Cloudns и Timeweb. Помимо DNS UPDATE есть web интерфейс и AXFR. Github.

Tier 1 сети по количеству маршрутов их клиентов. Тройка лидеров для single homed сетей, в этом больше всего смысла: Lumen(AS3356), Cogent(AS174) и Tata Comm(AS6453).
Но это если клиентов считать, а по количеству префиксов из одной AS в декабре расклад был такой. Сейчас на коллекторе RRC0 (@FullViewBGPbot) видно, что в IPv4 из одной AS максимально анонсируется почти 13000 префиксов, а в IPv6 близко к 6000.

Даже уже в Сомали на IPv6 переходят. С другой стороны, государственная поддержка дело такое, IPv4 сам всего добился. Так что лучше самим, пока государство по полной не вмешалось.

А не в Сомали можно получить LIR специальльно для IPv6, номер автономной системы, /29 префикс и всё равно настраивать Wireguard на микротике и виртуалку, чтобы прокинуть себе домой /48. Но провайдера который не захотел пириться с таким энтузиастом тоже можно понять, выглядит немного чересчур.

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

Анализ изменений с 2018 года точек присутствия для больших CDN, таких как Amazon, Cloudflare, Akamai, Google, Microsoft, Fastly и других, по данным PeeringDB. Все растут. В конце статьи есть ссылки на интерактивные карты в динамике и графики. В России, по этим данным, ничего из перечисленного нет (почти) и никогда не было.

IPv4 всё ещё нужны настолько, что под их залог можно брать кредит и не важно что они вам не принадлежат, а только за вами числятся. Ждём когда IPv6 перевернёт эту доску.

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